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Preface 



Vous avez entre les mains un ouvrage remarquable, probablement le premier dans 
son genre. Consacre aux developpeurs C++ deja experimented, il apporte un eclairage 
nouveau sur le langage : de la robustesse aux exceptions aux subtilites des espaces de 
nommage, des ressources cachees de la bibliotheque standard a l'emploi judicieux de 
l'heritage, tous les sujets sont abordes dans le contexte de leur utilisation profession- 
nelle. Des surprises que peuvent reserver les iterateurs, les algorithmes de resolution 
de noms ou les fonctions virtuelles aux techniques permettant de concevoir efficace- 
ment des classes, de minimiser les dependances au sein d'un programme ou d'utiliser 
au mieux les modeles generiques, la majorite des techniques et des pieges du C++ 
sont passees en revue sous la forme de cas pratiques tres pertinents. 

Au fur et a mesure de ma lecture, en comparant mes solutions a celles proposees 
par Sutter, je me suis vu tomber dans des pieges bien plus souvent que je n'aimerais 
l'admettre. Ceci pourrait, certes, s'expliquer par une insuffisante maitrise du langage. 
Mon opinion est plutot que tout developpeur, si experimente qu'il soit, doit etre tres 
prudent face a la puissance du C++, arme a double tranchant. Des problemes comple- 
xes peuvent etre resolus avec le C++, a condition de parfaitement connaitre les avanta- 
ges mais aussi les risques des nombreuses techniques disponibles. C'est justement 
l'objet de ce livre, qui sous la forme originale de problemes resolus, inspires d'articles 
initialement parus sur 1' Internet dans « Guru Of The Week », fait un tour complet du 
langage et de ses fonctionnalites. 

Les habitues des groupes de discussion Internet savent a quel point il est difficile 
d'etre elu « gourou » de la semaine. Grace a ce livre, vous pourrez desormais preten- 
dre ecrire du code de « gourou » chaque fois que vous developperez. 

Scott Meyers 
Juin 1999 



v 



© copyright Editions Eyrolles 



Avant-propos 



Ce livre a pour but de vous aider a ecrire des programmes plus robustes et plus 
performants en C++. La majorite des techniques de programmation y sont abordees 
sous la forme de cas pratiques, notamment inspires des 30 premiers problemes initia- 
lement parus sur le groupe de discussion Internet « Guru of The Week 1 ». 

Le resultat n'est pas un assemblage disparate d'exemples : cet ouvrage est, au con- 
traire, specialement concu pour etre le meilleur des guides dans la realisation de vos 
programmes professionnels. Si la forme probleme/solution a ete choisie, c'est parce 
qu'elle permet de situer les techniques abordees dans le contexte de leur utilisation 
reelle, rendant d'autant plus profitable la solution detaillee, les recommandations et 
discussions complementaires proposees au lecteur a l'occasion de chaque etude de 
cas. Parmi les nombreux sujets abordes, un accent particulier est mis sur les themes 
cruciaux dans le cadre du developpement en entreprise : robustesse aux exceptions, 
conception de classes et de modules faciles a maintenir, utilisation raisonnee des opti- 
misations, ecriture de code portable et conforme a la norme C++. 

Mon souhait est que cet ouvrage vous accompagne efficacement dans votre travail 
quotidien, et, pourquoi pas, vous fasse decouvrir quelques unes des techniques elegan- 
tes et puissantes que nous offre le C++. 

Comment lire ce livre ? 

Avant tout, ce livre s'adresse aux lecteurs ayant deja une bonne connaissance du 
langage C++. Si ce n'est pas encore votre cas, je vous recommande de commencer par 
la lecture d'une bonne introduction au langage (The C+ + Programming Language 2 



1 . Litteralement : le « gourou » de la semaine. 

2. Stroustrup B. The C+ + Programming Language, Third Edition (Addison Wesley Long- 
man, 1997) 

vii 
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de Bjarne Stroustrup ou C+ + Primer, de Stan Lippman et Josee Lajoie), et 
l'incontournable classique de Scott Meyer : Effective C++ (la version CD-Rom est 
tres facile d'emploi) 2 . 

Chacun des problemes est presente de la maniere suivante : 



Pb n°##. Titre du Probleme Difficulte : X 



Le chiffre indiquant la difficulte varie en pratique entre 3 et 9 ' ' sur une echelle de 
10. Cette valeur subjective indique plus les difficultes relatives des differents proble- 
mes que leur difficulte dans l'absolu : tous les problemes sont techniquement aborda- 
bles pour un developpeur C++ experiments . 

Les problemes n'ont pas necessairement a etre lus dans l'ordre, sauf dans le cas de 
certaines series de problemes (indiques " l re partie », « 2 e partie »...) qu'il est profita- 
ble d'aborder d'un bloc. 

Ce livre contient un certain nombre de recommandations, au sein desquelles les 
termes sont employes avec un sens bien precis : 

■ (employez) systematiquement : il est absolument necessaire, indispensable, 
d' employer telle ou telle technique. 

■ preferez (l'emploi de): l'emploi de telle ou telle technique est 1' option la plus 
usuelle et la plus souhaitable. N'en deviez que dans des cas bien particuliers lors- 
que le contexte le justifie. 

■ prenez en consideration : l'emploi de telle ou telle technique ne s'impose pas, 
mais merite de faire l'objet d'une reflexion. 

■ evitez (l'emploi) : telle ou telle technique n'est certainement pas la meilleure a 
employer ici, et peut meme s'averer dangereuse dans certains cas. Ne l'utilisez que 
dans des cas bien particuliers, lorsque le contexte le justifie. 

■ (n'employez) jamais : il est absolument necessaire, crucial, de ne pas employer 
telle ou telle technique. 

Comment est nee I'idee de ce livre ? 

L'origine de ce livre est la serie « Guru of the Week », initialement creee dans le 
but de faire progresser les equipes de developpements internes de PeerDirect en leur 
soumettant des problemes pratiques pointus et riches en enseignements, abordant tant 



1. Lippman S. and Lajoie J. C++ Primer, Third Edition (Addison Wesley Longman, 1998) 

2. Meyer S. Effective C++ CD : 85 Specific Ways to Improve Your Programs and Designs 
(Addison Wesley Longman 1999). Voir aussi la demonstration en-ligne sur http:// 
www.meyerscd.awl.com 
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Futilisation de techniques C++ (emploi de 1' heritage, robustesse aux exceptions), que 
les evolutions progressives de la norme C++. Forte de son succes, la serie a ete par la 
suite publiee sur le groupe de discussion Internet comp.iang.c++. moderated, sur 
lequel de nouveaux problemes sont desormais regulierement soumis. 

Tirer parti au maximum du langage C++ est un souci permanent chez nous, a Peer- 
Direct. Nous realisons des systemes de gestion de bases de donnees distribuees et de 
replication, pour lesquels la fiabilite, la robustesse, la portabilite et la performance 
sont des contraintes majeures. Nos logiciels sont amenes a etre portes sur divers com- 
pilateurs et systemes d' exploitation, ils se doivent d'etre parfaitement robustes en cas 
de defaillance de la base de donnees, d' interruption des communications reseau ou 
d' exceptions logicielles. De la petite base de donnees sur PalmOS ou Windows CE 
jusqu'aux gros serveurs de donnees utilisant Oracle, en passant par les serveurs de 
taille moyenne sous Windows NT, Linux et Solaris, tous ces systemes doivent pouvoir 
etre geres a partir du meme code source, pres d'un demi-million de lignes de code, a 
maintenir et a faire evoluer. Un redoutable exercice de portabilite et de fiabilite. Ces 
contraintes, ce sont peut etre les votres. 

Cette preface est pour moi l'occasion de remercier les fideles lecteurs de Guru of 
the Week pour tous les messages, commentaires, critiques et requetes au sujet des pro- 
blemes publies, qui me sont parvenus ces dernieres annees. Une de ces requetes etait 
la parution de ces problemes sous forme d'un livre ; la void exaucee, avec, au pas- 
sage, de nombreuses ameliorations et remaniements : tous les problemes ont ete revi- 
ses, mis en conformite avec la norme C++ desormais definitivement etablie, et, pour 
certains d'entre eux, largement developpes - le probleme unique consacre a la gestion 
des exceptions est, par exemple, devenu ici une serie de dix problemes. En conclusion, 
les anciens lecteurs de Guru of the Week, trouverons ici un grand nombre de nouveau- 
tes. 

J'espere sincerement que ce livre vous permettra de parfaire votre connaissance 
des mecanismes du C++, pour le plus grand benefice de vos developpements logiciels. 

Remerciements 

Je voudrais ici exprimer toute ma reconnaissance aux nombreux lecteurs enthou- 
siastes de Guru of the Week, notamment pour leur participation active a la recherche 
du titre de ce livre. Je souhaiterais remercier tout particulierement Marco Dalla Gas- 
perina, pour avoir propose Enlightened C+ + et Rob Steward pour avoir propose Prac- 
tical C++ Problems et Solutions. L' assemblage de ces deux suggestions ont conduit 
au titre final 1 , a une petite modification pres, en reference a l'accent particulier mis, 
dans ce livre, sur la gestion des exceptions. 

Merci a Bjarne Stroustrup, responsable de la collection C++ In-Depth Series, 
ainsi qu'a Marina Lang, Debbie Lafferty, et a toute l'equipe editoriale de Addison 



1. NdT : Le titre original de ce livre est « Exceptional C++ : 47 Engineering Puzzles , 
Programming problems, and Solutions ». 
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Wesley Longman 1 pour leur enthousiasme, leur disponibilite permanente, et pour la 
gentillesse avec laquelle ils ont organise la reception lors de la reunion du comite de 
normalisation a Santa Cruz. 

Merci egalement a tous les relecteurs, parmi lesquels se trouvent d'eminents mem- 
bres du comite de normalisation C++, pour leurs remarques pertinentes et les amelio- 
rations qu'ils m'ont permis d'apporter au texte : Bjarne Stroustrup, Scott Meyers, 
Andrei Alexandrescu, Steve damage, Steve Dewhurst, Cay Horstmann, Jim Hyslop, 
Brendan Kehoe et Dennis Mancl. 

Merci, pour finir, a ma famille et a tous mes amis, pour leur soutien sans faille. 

Herb Sutter 
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1. NdT : Editeur de 1' edition originale. 
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Programmation generique 
avec la bibliotheque standard 

C++ 



Pour commencer, nous etudierons quelques sujets relatifs a la programmation 
generique en nous focalisant en particulier sur les divers elements reutilisables 
(conteneurs, iterateurs, algorithmes) fournis par la bibliotheque standard C++. 



Pb n° 1 . Iterateurs 



Difficulte : 7 



Les iterateurs sont indissociables des conteneurs, dont ils permettent de manipuler les elements. 




Examinez le programme suivant. II comporte un certain nombre d'erreurs dues a 
une mauvaise utilisation des iterateurs (au moins quatre). Pourrez-vous les identifier ? 

int main ( ) 
{ 

vector<Date> e; 

copy ( istream_iterator<Date> ( cin ), 
istream_iterator<Date> () , 
back_inserter ( e ) ) ; 

vector <Date> :: iterator first = 

find( e.beginO, e.endO, "01/01/95" ); 

vector <Date> :: iterator last = 

find( e.beginO, e.endO, "31/12/95" ); 
*last = "30/12/95"; 

1 
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copy ( first, 
last, 

ostream_iterator<Date> ( cout, "\n" ) ); 
e. insert ( — e . end ( ) , DateDuJourO ) ; 
copy ( first, 

last, 

ostream_iterator<Date> ( cout, "\n" ) ); 

} 



Examinons ligne par ligne le code propose : 

int main ( ) 
{ 

vector<Date> e; 

copy ( istream_iterator<Dathe> ( cin ), 
istream_iterator<Date> () , 
back_inserter ( e ) ) ; 

Pour 1' instant, pas d'erreur. La fonction copy ( ) effectue simplement la copie de dates 
dans le tableau e. On fait neanmoins Fhypothese que l'auteur de la classe Date a fourni 
une fonction operator» (i st reams, Dates) pour assurer le bon fonctionnement de Fins- 
truction istream_iterator<Date> (cin) , qui lit une date apartir du flux d'entree cin. 

vector<Date> :: iterator first = 

find( e.beginO, e.endO, "01/01/95" ); 
vector<Date> :: iterator last = 

find( e.beginO, e.endO, "31/12/95" ) ; 
*last = "30/12/95"; 

Cette fois, il y a une erreur ! Si la fonction find ( ) ne trouve pas la valeur deman- 
ded, elle renverra la valeur e . end ( ) , l'iterateur last sera alors situe au-dela de la fin 
de tableau et Finstruction « *iast= "30/12/95" » echouera. 

copy ( first, 
last, 

ostream_iterator<Date> ( cout, "\n" ) ) ; 

Nouvelle erreur ! Au vu des lignes precedentes, rien n'indique que first pointe 
vers une position situee avant last, ce qui est pourtant une condition requise pour le 
bon fonctionnement de la fonction copy o . Pis encore, first et last peuvent tout a 
fait pointer vers des positions situees au-dela de la fin de tableau, dans le cas ou les 
valeurs cherchees n'auraient pas ete trouvees. 

Certaines implementations de la bibliotheque standard peuvent detecter ce genre 
de problemes, mais dans la majorite des cas, il faut plutot s'attendre a une erreur bru- 
tale lors de 1' execution de la fonction copy ( ) . 

e. insert ( — e.end(), DateDuJourO ) ; 

Cette ligne introduit deux erreurs supplementaires. 
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La premiere est que si vector<Date> : : iterator est de type Date* (ce qui est le 
cas dans de nombreuses implementations de la bibliotheque standard), l'instruction — 
e.endo n'est pas autorisee, car elle tente d'effectuer la modification d'une variable 
temporaire de type predefini, ce qui est interdit en C++. Par exemple, le code suivant 
est illegal en C++ : 

Date* f(); // f() est une fonction renvoyant une Date* 

Date* p = — f(); // Erreur ! 

Cette premiere erreur peut etre resolue si on ecrit : 

e.insert( e.end()-l, DateDuJour() ); 

La seconde erreur est que si le tableau e est vide, l'appel a e . end () -l echouera. 

copy ( first, 
last, 

ostream_iterator<Date> ( cout, "\n" ) ); 

Erreur ! Les iterateurs first et last peuvent tres bien ne plus etre valides apres 
1' operation d' insertion. En effet, les conteneurs sont realloues « par a-coups » en fonc- 
tion des besoins, lors de chaque operation d'insertion. Lors d'une reallocation, 
1' emplacement memoire ou sont stockes les objets contenus peut varier, ce qui a pour 
consequence d'invalider tous les iterateurs faisant reference a la localisation prece- 
dente de ces objets. L'instruction insert o precedant cette instruction copyo peut 
done potentiellement invalider les iterateurs last et first. 



Recommandation 

Assurez-vous de n'utiliser que des iterateurs valides. 



En resume, faites attention aux points suivants lorsque vous manipulez des iterateurs : 

■ N'utilisez un iterateur que s'il pointe vers une position valide. Par exemple, l'ins- 
truction « *e . end ( ) » provoquera une erreur. 

■ Assurez-vous que les iterateurs que vous utilisez n 'ont pas ete invalides par une 
operation survenue auparavant. Les operations d'insertion, notamment, peuvent 
invalider des iterateurs existants si elles effectuent une reallocation du tableau 
contenant les objets. 

■ Assurez-vous de transmettre des intervalles d' iterateurs valides auxfonctions qui 
le requierent. Par exemple, la fonction findo necessite que le premier iterateur 
pointe vers une position situee avant le second ; assurez-vous egalement, que les 
deux iterateurs pointent vers le meme conteneur ! 

■ Ne tentez. pas de modifier une valeur temporaire de type predefini. En particulier, l'ins- 
truction « — e . end ( ) » VUe ci-deSSUS prOVOque une erreur si vector<Date> : : itera- 
tor est de type pointeur (dans certaines implementations de la bibliotheque standard, il 
se peut que Fiterateur soit de type objet et que la fonction operator ( ) — ait ete redefi- 
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Programmation generique avec la bibliotheque standard C++ 



nie pour la classe correspondante, rendant ainsi la syntaxe « — e.endo » autorisee ; 
cependant, il vaut mieux l'eviter dans un souci de portabilite du code). 



Pb n° 2. Chaines insensibles a la casse 

(1 re partie) Difficulte : 7 



L'objet de ce probleme est d'implementer une classe chaTne « insensible a la casse », apres avoir 
precise ce que cela signifie. 



1 . Que signifie etre « insensible a la casse » pour une chaine de caracteres ? 

2. Implementez une classe ci_string se comportant de maniere analogue a la classe 
standard std: : string mais qui soit insensible a la casse, comme Test la fonction 
stricmp { ) l . Un objet ci_string doit pouvoir etre utilise de la maniere suivante : 

ci_string s( "AbCdE" ); 

// Chaine insensible a la casse 

// 

assert ( s == "abcde" ) ; 
assert ( s == "ABCDE" ) ; 

// 

// La casse originate doit etre conservee en interne 
assert ( strcmp ( s.c_str(), "AbCdE" ) ==0 ); 
assert ( strcmp ( s.c_str(), "abcde" ) ! = 0 ) ; 

3. Une classe de ce genre est-elle utile ? 



Solution 




1 . Que signifie etre « insensible a la casse » pour une chaine de caracteres ? 

Etre « insensible a la casse » signifie ne pas faire la difference entre majuscules et 
minuscules. Cette definition generale peut etre modulee en fonction de la langue utili- 
see : par exemple, pour une langue utilisant des accents, etre « insensible a la casse » 
peut eventuellement signifier ne pas faire de difference entre lettres accentuees ou 
non. Dans ce probleme, nous nous cantonnerons a la premiere definition. 

2. Implementez une classe ci_string se comportant de maniere analogue a la classe 
standard std: -.string mais qui soit insensible a la casse, comme Vest la fonction 

stri cmp ( ) . 



1. La fonction stricmp ( ) ne fait pas partie de la bibliotheque standard a proprement par- 
ler mais est fournie avec de nombreux compilateurs C et C++. 
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Commencons par un petit rappel sur la classe string de la bibliotheque standard. 
Un coup d'oeil dans le fichier en-tete <string> nous permet de voir que string est 
en realite un modele de classe : 

typedef basic_string<char> string; 

Le modele de classe basic_string est, pour sa part, declare de la maniere suivante : 

template<class charT, 

class traits = char_traits<charT>, 

class Allocator = allocator<charT> > 
class basic_string; 

En conclusion, string signifie en fait : 

basic_string<char , char_traits<char>, allocator<char>> 

Autrement dit, string est une instanciation de basic_string avec le type char 
pour lequel on utilise les parametres par defaut du modele de classe. Parmi ces para- 
metres, le deuxieme peut nous interesser tout particulierement : il permet en effet de 
specifier la maniere dont les caracteres seront compares. 

Rentrons un peu dans le detail. Les capacites de comparaison fournies par 
basic_string sont en realite fondees sur les fonctions correspondantes de 
char_traits, a savoir eq() et it ( ) pour les tests d'egalite et les comparaisons de 
type « est inferieur a » entre deux caracteres ; compare ( ) et find { ) pour la comparai- 
son et la recherche de sequences de caracteres. 

Pour implementer une chaine insensible a la casse, le plus simple est done 
d'implementer notre propre classe derivee de char_traits : 

struct ci_char_traits : public char_traits<char> 

// On redefinit les fonctions dont on souhaite 
// specialiser le comportement 

{ 

static bool eq ( char cl, char c2 ) 

{ return toupper(cl) == toupper(c2); } 

static bool It ( char cl, char c2 ) 

{ return toupper(cl) < toupper(c2); } 

static int compare) const char* si, 

const char* s2, 
size_t n ) 
{ return memicmp ( si, s2, n ) ; } 

// memicmp n'est pas fournie pas tous les compilateurs 
// En cas d' absence, elle peut facilement etre implementee. 

static const char* f ind ( const char* s, int n, char a ) 

{ 

while ( n— > 0 && toupper(*s) != toupper(a) ) 

{ 

++s; 

} 

return n > 0 ? s : 0; 
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Ce qui nous amene finalement a la definition de notre classe insensible a la casse : 

typedef basic_string<char , ci_char_traits> ci_string; 

II est interessant de noter 1' elegance de cette solution : nous avons reutilise toutes 
les fonctionnalites du type string standard en remplacant uniquement celles qui ne 
convenaient pas. C'est une bonne demonstration de la reelle extensibility de la biblio- 
theque standard. 

3. Une classe de ce genre est-elle utile ? 

A priori, non. II est en general plus clair de disposer d'une fonction de comparai- 
son a laquelle on peut specifier de prendre en compte ou non la casse, plutot que deux 
types de chaine distincts. 

Considerons par exemple le code suivant : 

string a = "aaa"; 
ci_string b = "aAa"; 
if ( a == b ) /* ... */ 

Quel doit etre le resultat de la comparaison entre a et b ? Faut-il prendre en compte 
le caractere sensible a la casse de l'operande de gauche et effectuer une comparaison 
sensible a la casse ? Faut-il au contraire faire predominer l'operande de droite et effec- 
tuer une comparaison insensible a la casse ? On pourrait certes, par convention, adop- 
ter une option ou 1' autre. Mais cela ne ferait qu'eluder le probleme sans le resoudre. 
Pour vous en convaincre, imaginez un troisieme mode de comparaison implemente 
par les chaines de type yz_string : 

typedef basic_string<char , yz_char_traits> yz_string; 

ci_string b = "aAa"; 
yz_string c = "AAa"; 
if ( b == c ) /* ... */ 

Quel doit etre le resultat de la comparaison entre b et c ? II apparait ici clairement 
qu'il n'y aucune raison valable de preferer un mode de comparaison a 1' autre. 

Si en revanche, le mode de comparaison utilise est specifie par l'emploi d'une fonc- 
tion particuliere au lieu d'etre lie au type des objets compares, tout devient plus clair : 

string a = "aaa"; 
string b = "aAa"; 

if( stricmp( a.c_str(), b.c_str() )== 0 )/*... */ 
string c = "AAa"; 

if ( EstEgalAuSensDeLaComparaisonYZ ( b, c ) ) /* ... */ 

Dans la majorite des cas, il est done preferable que le mode de comparaison 
depende de la fonction utilisee plutot que du type des objets compares. Neanmoins, 
dans certains cas, il peut etre utile d'implementer une classe de maniere a ce qu'elle 
puisse etre comparee a des objets ou variables d'un autre type : par exemple, il est 
interessant que les objets de type string puissent etre compares naturellement a des 

char*. 
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En resume, ce probleme a permis de mettre en lumiere le fonctionnement interne 
de basic_string et d'indiquer une maniere elegante et efficace de reutiliser ce 
modele de classe, dans le cas ou on souhaite personnaliser les fonctions des comparai- 
son utilisees par une chaine de caractere. 



Pb n° 3. Chaines insensibles a la casse 

(2 e partie) Difficulte : 5 



Independamment de son utilite pratique qui pourrait etre discutee ailleurs, peut-on dire que la 
classe ci_string implemented dans le probleme precedent estfiable techniquement ? 



Reprenons la declaration de la classe ci_string vue dans le probleme precedent : 

struct ci_char_traits : public char_traits<char> 
{ 

static bool eq ( char cl, char c2 ) { /*...*/ } 
static bool It ( char cl, char c2 ) {/*...*/} 
static int compare ( const char* si, 

const char* s2, 

size_t n ) {/*...*/} 

static const char* 

find( const char* s, int n, char a ) { /*...*/ } 

}; 

1. Est-il techniquement fiable de faire deriver ainsi ci_char_traits de 

char_traits <char> ? 

2. Le code suivant se compilera-t-il correctement ? 

ci_string s = "abc"; 
cout << s << endl; 

3. Est-il possible d'utiliser les operateurs d'addition et d'affectation (+,+= et =) en 
melangeant les types des operandes (string et ci_string), comme le montre 
l'exemple ci-dessous? 

string a = "aaa"; 
ci_string b = "bbb"; 
string c = a + b; 



-(^- Solution 



1. Est-il techniquement fiable de faire deriver ainsi ci_char_traits de 

char_traits<char> ? 
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Comme le precise le principe de substitution de Liskov 1 , F utilisation de F heritage 
public doit normalement etre reservee a F implementation d'une relation de type « EST- 
UN » ou « FONCTIONNE-COMME-UN » entre la classe de base et la classe derivee. On 
peut done considerer qu'une derivation publique ne se justifie pas dans notre exemple, 
etant donne que les objets ci_char_traits<char> ne seront pas amenes a etre utilises de 
maniere polymorphique a partir d'un pointeur de type char_traits<char>. La derivation 
est done utilisee ici plutot par paresse et contort d' utilisation que par reel besoin. 

Nathan Myers 2 precise avec raison que lorsque l'on instancie un modele de classe 
avec un type donne, il faut s' assurer que ce type est compatible avec les exigences 
requises par le modele : cette regie est plus connue sous le nom du « principe generi- 
que de substitution de Liskov 3 ». 

Dans notre cas, nous devons done nous assurer que la classe ci_char_traits 
repond bien aux exigences du modele de classe basic_string, a savoir que le type 
passe en deuxieme parametre doit avoir la meme interface publique que le modele de 

classe char_traits. 

Le fait que ci_char_traits derive de char_traits nous assure que ce dernier 
point est verifie et confirme done la validite technique cette classe. 

En resume, F utilisation de la derivation est suffisante car elle nous assure le res- 
pect du « Principe Generique de Substitution de Liskov » ; elle n'est en revanche pas 
necessaire car elle assure, en plus, le respect du « Principe de Substitution de Liskov » 
proprement dit, ce qui n'est en Foccurrence pas requis. 

L'heritage a done ete utilise ici par commodite. C'est d'autant plus flagrant que la 
classe ci_char_traits ne comporte que des membres statiques et que la classe 
char_traits ne peut pas etre utilisee de maniere polymorphique. Nous aurons 
Foccasion de revenir plus tard sur les raisons qui justifient Femploi de l'heritage (pro- 
bleme n° 24). 

2. Le code suivant se compiler a-t-il correctement ? 

ci_string s = "abc"; 
cout << s << endl; 

Petite indication : il est specific: dans la norme C++ [21.3.7.9, lib.string.io] que la 
declaration de Foperateur << pour la classe basic_string doit etre la suivante : 

template<class charT, class traits, class Allocator> 

basic_ostream<charT, traits>& 

operator<< (basic_ostream<charT, traits>& os, 

const basic_string<charT, trait s , Allocator>& str) ; 

Par ailleurs, rappelons que Fobjet cout est de type basic_ostream<char, 

char_traits<char>. 



1. Liskov Substitution Principle (LSP). Voir a ce sujet les problemes n° 22 et 28. 

2. Nathan Myers est membre de longue date de comite de normalisation C++. II est, en 
particulier, l'auteur de la classe locale de la bibliotheque standard. 

3. Generic Liskov Substitution Principle (GLSP). 
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A partir de ces elements, il apparait clairement que le code ci-dessus pose un pro- 
bleme : en effet, l'operateur << est un modele de fonction faisant lui meme appel a 
deux autres modeles basic_ostream et basic_string auxquels il passe des parame- 
tres. L' implementation de operator<< ( ) est telle que le deuxieme parametre (traits) 
est necessairement le meme pour chacun de ces deux modeles. Autrement dit, l'opera- 
teur « qui permettra d'afficher un ci_string devra accepter une premiere operande 
de type basic_ostream<char, ci_char_traits>, ce qui n'est malheureusement pas le 
type de cout. Le fait que ci_char_traits derive de char_traits n'ameliore en rien 
le probleme. 

II y a deux moyens de resoudre le probleme : definir votre propre operate ur << 
pour la classe ci_string (il faudrait alors, pour etre coherent, definir egalement l'ope- 
rateur >>) ou bien utiliser la fonction membre c_str ( ) pour se ramener au cas classi- 

que d'operator<< (const char*) : 

cout << s.c_str() << endl; 

3. Est-il possible d'utiliser les operateurs d 'addition et d 'affectation (+,+= et =) en 
melangeant les types des operandes (string et ci_string), comme le montre 
Vexemple ci-dessous? 

string a = "aaa"; 
ci_string b = "bbb"; 
string c = a + b; 

La encore, la reponse est non. Pour s'en sortir, il faut redefinir une fonction opera- 
tort ( ) specifique ou utiliser la fonction c_str ( ) pour se ramener a l'utilisation de 

operatort (const char*). 



Pb n° 4. Conteneurs generiques reutilisables 

(1 re partie) Difficulte : 8 



Comment rendre un conteneur le plus generique possible ? Dans quelle mesure le fait d'avoir 
des membres de type parametrable a t-il un impact sur le spectre des utilisations possibles d'un 
lodele de classe ? 



modele de class 



J 



Voici une declaration possible pour une classe f ixed_vector, similaire a la classe 
vector de la bibliotheque standard, permettant d'implementer un tableau de taille fixe 
contenant des elements de type parametrable : 



class f ixed_vector 



public : 

typedef T* iterator; 
typedef const T* const_iterator ; 



iterator 
iterator 



begin ( ) 
end() 



return v_; } 
return v_+size; 
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const_iterator begin () const { return v_; } 
const_iterator end() const { return v_+size; ) 

private : 

T v_ [ size] ; 

>; 

Proposez une implementation pour le constructeur de copie et l'operateur d'affec- 
tation de cette classe (leurs declarations ne sont pas mentionnees ici). Efforcez-vous 
de le rendre le plus generique possible : en particulier, tentez de reduire au minimum 
les contraintes imposees au type t contenu. 

Concentrez-vous sur ces deux fonctions et ne tenez pas compte des autres imper- 
fections de cette classe, qui n'est de toute facon pas parfaitement compatible avec les 
exigences de la bibliotheque standard. 




Nous allons, pour une fois, adopter une technique un peu differente : nous propo- 
sons une implementation possible pour le constructeur de copie et l'operateur d' affec- 
tation de la classe f ixed_vector dans l'enonce du prochain probleme. Voire role sera 
de la critiquer. 



PB N° 5. CONTENEURS GENERIQUES REUTILISABLES 

(2 e partie) Difficulte : 6 



Nous presentons done ici la solution du probleme precedent. Precisons que I'exemple de 
f ixed_vector est inspire d'une publication originale de Kevlin Henney, completee plus tard par 
les analyses de Jon Jagger parues dans les numeros 12 a 20 du magazine « overload ». Preci- 
sons aux lecteurs ayant eu connaissance du probleme sous sa forme originale que nous presen- 
tons ici une solution legerement differente (en particulier, les optimisations presentees dans le 
n° 20 de « Overload » ne fonctionneront pas avec notre solution). 



Voici une implementation possible pour le constructeur de copie et l'operateur 
d'affectation de f ixed_vector : 

template<typename T, size_t size> 

class fixed_vector 

{ 

public : 

typedef T* iterator; 
typedef const T* const_iterator ; 
f ixed_vector ( ) { } 
template<typename 0, size_t osize> 
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f ixed_vector ( const f ixed_vector<0, osize>& other ) 
{ 

copy ( other . begin ( ) , 

other .begin ( ) +min (size, osize) , 
begin ( ) ) ; 

} 

template<typename O, size_t osize> 
f ixed_vector<T, size>& 

operator= ( const f ixed_vector<0, osize>& other ) 
{ 

copy ( other . begin ( ) , 

other .begin ( ) +min (size, osize) , 

begin ( ) ) ; 
return *this ; 

} 

iterator 
iterator 
const_iterator 
const_iterator 

private : 

T v_[size] ; 

}; 

Commentez ces implementations. Presentent-elles des defauts ? 




Nous allons analyser les fonctions presentees ci-dessus notamment du point de 
vue de leur reutilisabilite et des contraintes qu'elles imposent au type t contenu. 

Constructeur de copie et operateur d 'affectation 

Une remarque preliminaire s'impose : la classe fixed_vector n'a en realite pas 
besoin d'un constructeur de copie et d'un operateur d' affectation specifique ; les fonc- 
tions fournies par defaut par le compilateur fonctionnent parfaitement ! 

La question posee etait en quelque sorte un piege... 

Neanmoins, il est vrai que ces fonctions par defaut limitent la reutilisabilite de la 
classe f ixed_vector , notamment en presence de diverses instances contenant des 
types differents. L'objet de cette solution est done de proposer 1' implementation d'un 
constructeur de copie et d'un operateur d' affectation parametrables, afin de rendre la 
classe f ixed_vector plus souple d' utilisation. 



begin () { return v_; } 

end ( ) { return v_+size; } 

begin () const { return v_; } 

end() const { return v tsize; } 
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f ixed_vector ( const f ixed_vector<0, osize>& other ) 
{ 

copy ( other . begin ( ) , 

other .begin () +min (size, osize) , 
begin () ); 

} 

template<typename 0, size t osize> 
f ixed_vector<T, size>& 

operator= ( const f ixed_vector<0, osize>& other ) 
{ 

copy ( other . begin ( ) , 

other . begin () +min (size, osize) , 

begin () ); 
return *this; 

} 

Notons tout de suite que les fonctions ci-dessus ne constituent pas a proprement 
parler un constructeur de copie et un operateur d' affectation, car ce sont des modeles 
de fonctions membres pour lesquels les types passes en parametre ne sont pas neces- 
sairement du type de la classe : 

struct X 
{ 

template<typename T> 

X( const T& ) ; // N' est PAS un constructeur de copie 
// II se peut que T ne soit pas X 

template<typename T> 

operator= ( const T& ) ; 

// N' est PAS un operateur d' affectation 
// II se peut que T ne soit pas X 

}; 

Si le type t est remplace par x, nous obtenons des fonctions ayant la meme signa- 
ture qu'un constructeur de copie et un operateur d' affectation. Neanmoins, la pre- 
sence de ces modeles de fonction ne dispense pas le compilateur d'implementer un 
constructeur de copie et un operateur d' affectation par defaut, comme le precise la 
section 12.8/2 (note 4) de la norme C++ : 

La presence d'un modele de fonction membre ayant la meme signature 
qu'un constructeur de copie ne supprime pas la declaration implicite du 
constructeur de copie par defaut. Les modeles de constructeurs sont pris 
en compte par I'algorithme de resolution des noms pour les appels de 
fonctions ; on peut tout a fait les preferer a un constructeur normal si leur 
signature correspond mieux a la syntaxe de I'appel. 

Un paragraphe similaire est consacre, un peu plus loin, a 1' operateur d' affectation 
(12.8/9 note 7). En pratique, les fonctions par defaut, deja presentes dans l'implemen- 
tation originale, existent toujours dans notre nouvelle version de f ixed_vector : nous 
ne les avons pas remplacees ; nous avons au contraire ajoute deux nouvelles fonctions. 
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Pour bien illustrer la difference entre ces quatre fonctions, considerons l'exemple 
suivant : 

f ixed_vector<char, 4> v; 
f ixed_vector<int , 4 > w; 

f ixed_vector<int , 4 > w2 (w) ; 

// Appelle le constructeur de copie par defaut 
f ixed_vector<int , 4 > w3 (v) ; 

// Appelle le modele de constructeur de copie 
w = w2 ; 

// Appelle 1' operateur d' affectation par defaut 
w = v; 

// Appelle le modele d' operateur d' affectation 

En resume, nous avons implemente ici des fonctions supplementaires permettant 
de construire ou de realiser une affectation vers un fixed_vector depuis un 

fixed_vector d'un autre type. 



Spectre d'utilisation de la classe f ixed_vector 

Dans quelle mesure notre classe f ixed_vector est-elle utilisable ? 

Pour etre utilisee dans de nombreux contextes, fixed_vector doit etre perfor- 
mante sur deux points : 

■ Capacite a gerer des types heterogenes 

II doit etre possible de construire une instance de f ixed_vector a partir d'un autre 
fixed_vector contenant des objets de type different dans la mesure ou le type de 
l'objet source est convertible dans le type de l'objet cible (idem pour 1' affectation). 

Autrement dit, il faut qu'il soit possible d'ecrire : 

f ixed_vector<char, 4> v; 

f ixed_vector<int , 4 > w(v); 

// Appel au modele de constructeur de copie 
w = v; 

// Appel au modele d' operateur d' affectation 

class B {/*...*/}; 
class D : public B { /*...*/ }; 

f ixed_vector<D* , 4> x; 

f ixed_vector<B* , 4> y(x); 

// Appel au modele de constructeur de copie 
y = x; 

// Appel au modele d' operateur d' affectation 
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Ceci fonctionne car une variable de type d* peut etre affectee a une variable de 
type b*. 

■ Capacite a gerer des tableaux de taille differente. 

II doit etre possible d'affecter la valeur d'un tableau a un autre tableau de taille dif- 
ferente, par exemple : 

f ixed_vector <char , 6> v; 

f ixed_vector <int , 4> w(v); 

// Initialise w en utilisant les 4 premieres valeurs de v 
w = v; 

// Affecte a w les 4 valeurs de v 

class B {/*...*/}; 
class D : public B { /*...*/ }; 

f ixed_vector<D* , 1 6> x; 

f ixed_vector <B* , 42> y(x); 

// Initialise y en utilisant le 16 premieres valeurs de x 
y = x; 

// Affecte a y les 16 valeurs de x 



Solution adoptee par la bibliotheque standard 

De nombreux conteneurs de la bibliotheque standard fournissent des fonctions de 
copie et d' affectation similaires. Celles-ci sont neanmoins implementees sous une 
forme legerement differente, que nous exposons ici. 

1 . Constructeur de copie 

template<class Iter> 

f ixed_vector ( Iter first, Iter last ) 
{ 

copy ( first, 

f ir st+min ( size , ( size_t ) last-first) , 
begin () ); 

} 

iter designe un type d'iterateur. 

Avec notre implementation, nous ecrivions : 

f ixed_vector <char , 6> v; 

f ixed_vector <int , 4> w(v); 

// Initialise w a partir des 4 premieres valeurs de v 
Avec la version de la bibliotheque standard, cela donne : 

f ixed_vector <char , 6> v; 

f ixed_vector <int , 4> w(v.begin(), v.endO); 

// Initialise w a partir des 4 premieres valeurs de v 
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Aucune de ces deux versions ne s'impose veritablement par rapport a l'autre : 
notre implementation originale est plus simple d'emploi ; la deuxieme version pre- 
sente l'avantage d'etre plus flexible (l'utilisateur peut choisir la plage des objets a 
copier). 

2. Operateur d'affectation 

II n'est pas possible de fournir une implementation de l'operateur d'affectation 
prenant en parametre deux valeurs d'iterateurs : la fonction operator o= ne prend 
obligatoirement qu'un seul parametre. La bibliotheque standard fournit ici une fonc- 
tion nominee assign (affecter) : 

template<class Iter> 

f ixed_vector<T, size>& 

assign ( Iter first, Iter last ) 

{ 

copy ( first, 

f ir st +min (size, ( size_t ) last-first) , 

begin () ) ; 
return *this; 

} 

Avec notre implementation, nous ecrivions : 

w = v; 

// Copie les 4 premieres valeurs de v dans w 

La version de la bibliotheque standard ressemblerait a ceci : 

w . assign (v .begin (), v . end () ) ; 

// Copie les 4 premieres valeurs de v dans w 

Remarquons qu'on pourrait techniquement parlant se passer de la fonction 
assign ( ) . Ce ne serait qu'au prix d'une lourdeur d'ecriture supplementaire et d'une 
efficacite moindre : 

w = f ixed_vector<int , 4> (v . begin () , v.endO); 

// Initialise v et copie les 4 premieres valeurs de v dans w 

Quelle implementation preferer ? Celle de notre solution ou celle proposee par la 
bibliotheque standard ? L argument de plus grande flexibilite invoque pour le 
constructeur de copie ne tient plus ici. En effet, au lieu d'ecrire : 

w.assign( v.begin(), v.endO ); 

l'utilisateur peut tout a fait atteindre le meme niveau de flexibilite en ecrivant : 

copy ( v.begin(), v.begin{)+4, w.begin() ) ; 

II est done preferable d'utiliser la solution proposee initialement plutot que la 
fonction assign o, en se reservant la possibilite de recourir a copyo lorsque Ton 
souhaite affecter a un tableau cible un sous-ensemble d'un tableau source. 
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Pourquoi un constructeur par defaut explicite ? 

La solution proposee fournit un constructeur par defaut explicite, qui fait a priori 
la meme chose que le constructeur par defaut implicite du compilateur. Est-il neces- 
saire ? 

La reponse est claire et nette : a partir du moment ou nous declarons un 
constructeur dans une classe (meme s'il s'agit d'un modele de constructeur), le com- 
pilateur cesse de generer un constructeur par defaut. Or, nous avons clairement besoin 
d'un constructeur par defaut pour f ixed_vector, d'ou 1' implementation explicite. 

Un probleme persiste... 

La deuxieme question posee de l'enonce etait : « ce code presente-il des 
defauts ? » 

Malheureusement, oui : il risque de ne pas se comporter correctement en presence 
d'exceptions. Nous verrons plus loin en detail (problemes n° 8 a 11) les differents 
niveaux de robustesse aux exceptions. II y en a principalement deux : en presence 
d'une exception, une fonction doit correctement liberer toutes les ressources qu'elle 
se serait allouees (en zone memoire dynamique) et elle doit se comporter d'une 
maniere atomique (execution totale ou execution sans effet, les executions partielles 
etant exclues). 

Notre operateur d' affectation garantit le premier niveau de robustesse, mais pas le 
second. Reprenons le detail de 1' implementation : 

template<typename 0, size_t osize> 
f ixed_vector<T, size>& 

operator= ( const f ixed_vector<0, osize>& other ) 
{ 

copy ( other .begin () , 

other . begin ( ) +min (size, osize) , 

begin () ); 
return *this; 

} 

Si, au cours l'execution de la fonction copyo, une operation d' affectation d'un 
des objets t echoue sur une exception, la fonction operator= o se terminera prema- 
turement laissant l'objet f ixed_vector dans un etat incoherent, une partie seulement 
des objets contenus ayant ete remplacee. En d'autres termes, la fonction ne se com- 
porte pas d'une maniere atomique. 

II n'y a malheureusement aucun moyen de remedier a ce probleme avec Fimple- 
mentation actuelle de f ixed_vector. En effet : 

■ Pour obtenir une fonction operator= ( ) atomique, il faudrait normalement imple- 
menter une fonction swapt) capable d'echanger les valeurs de deux objets 
fixed_vector sans generer d'exception, puis implementer l'operateur = de 
maniere a ce qu'il realise 1' affectation sur un objet temporaire puis, en cas de reus- 
site de 1' operation, echange les valeurs de cet objet temporaire et de l'objet 
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principal. Cette technique du « valider ou annuler » sera etudiee en detail a 1' occa- 
sion du probleme n° 13. 

■ Or, il n'y a pas de moyen d'implementer une fonction swapo ne generant pas 
d'exception dans le cas de f ixed_vector, cette classe comportant une variable 
membre de type tableau qu'il n'est pas possible de copier de maniere atomique. 
Nous retrouvons, au passage, le probleme original de notre fonction operator ( ) =. 

II y a une solution pour s'en sortir : elle consiste a modifier 1' implementation 
interne de fixed_vector de maniere a stacker les objets contenus dans un tableau 
alloue dynamiquement. Nous obtenons ainsi une robustesse forte aux exceptions, au 
prix, il est vrai, d'une legere perte d'efficacite due aux operations d' allocation et de 
deallocation. 

// Une version robuste aux exceptions 

// 

template<typename T, size_t size> 

class fixed_vector 

{ 

public : 

typedef T* iterator; 
typedef const T* const_iterator ; 



fixed_vector () : v_( new T[size] ) { } 



~fixed_vector () { delete [] v_; } 



// Modele de constructeur 
template<typename O, size_t osize> 

f ixed_vector ( const f ixed_vector<0, osize>& other ) 

: v (new_T [size] ) 

{ 

try 
{ 

copy ( other . begin ( ) , 

other .begin ( ) +min (size, osize) , 
begin ( ) ) ; 

} 

catch (...) 
{ 

delete [] v_; 
throw; 

} 

} 

// Constructeur de copie explicite 

f ixed_vector ( const f ixed_vector<T, size>& other ) 

: v (new_T [size] ) 

{ 

try 
{ 

copy ( other . begin ( ) , 

other .begin () +min (size, osize) , 
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begin ( ) ) ; 

} 

catch (...) 
{ 

delete [] v_; 
throw ; 

} 

} 



void Swap ( f ixed_vector<T, size>& other ) throw () 
{ 

swap( v_, other. v_ ) ; 

} 

// Modele d' operateur d' affectation 
template<typename 0, size t osize> 
f ixed_vector<T, size>& 

operator= ( const f ixed_vector<0, osize>& other ) 
{ 

f ixed_vector<T, size> temp ( other ); 

Swap( temp ) ; // Ne peut pas lancer 

return *this; // d' exception .. . 

} 

// Operateur d' affectation explicite 
operator= ( const f ixed_vector<T, size>& other ) 

{ 

f ixed_vector<T, size> temp ( other ); 

Swap( temp ); // Ne peut pas lancer 

return *this; // d' exception .. . 

} 

iterator begin () { return v_; } 

iterator end() { return v_+size; ) 

const_iterator begin () const { return v_; } 

const_iterator end() const { return v_+size; ) 

private : 
T* v _; 



Erreur a eviter 

Ne considerez pas la gestion des exceptions comme un detail d'implementation. C'est au 
contraire un element primordial a prendre en compte des la conception de vos programmes. 



En conclusion, cet probleme a permis de demontrer l'utilite pratique des membres 
parametrables des modeles de classe. Bien qu'ils ne soient pas, a l'heure actuelle, pris 
en charge par tous les compilateurs - cela ne saurait tarder, puisqu'ils font maintenant 
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partie de la norme C++ standard - les membres parametrables permettent tres souvent 
d'elargir le spectre d' utilisation possible des modeles de classe. 



Pb n° 6. Objets temporaires 



Difficulte : 5 



Les compilateurs C++ ont, dans de nombreuses situations, recours a des objets temporaires. 
Ceux-ci peuvent degrader les performances d'un programme, voire poser des problemes plus 
graves s'ils ne sont pas maitrises par le developpeur. Etes-vous capable d'identifier tous les objets 
temporaires qui seront crees lors de I'execution d'un programme ? Lesquels peut-on eviter ? 
Nous apporterons ici des reponses a ces questions ; le probleme suivant, quant a lui, s'interes- 
sera a des obje.s temporaires par !a bibNotheque standard. | 

Examinez le code suivant : 

string TrouverAdresse ( list<Employe> emp, string nom ) 
{ 

for( list<Employe> :: iterator i = emp . begin () ; 
i ! = emp . end ( ) ; 
i++ ) 

{ 

if ( *i == nom ) 

{ 

return i->adresse; 

} 

} 

return ""; 

} 

L'auteur de ces lignes provoque l'utilisation d'au moins trois objets temporaires. 
Pouvez-vous les identifier ? Les supprimer ? 

Note : ne modifiez pas la structure generale de la fonction, bien que celle-ci puisse 
en effet etre amelioree. 




Aussi surprenant que cela puisse paraitre, cette fonction provoque l'utilisation de 
pas moins de sept objets temporaires ! 

Cinq d'entre eux pourraient facilement etre evites (trois sont faciles a reperer, les 
deux autres le sont moins). Les deux derniers sont inherents a la structure de la fonc- 
tion et ne peuvent pas etre supprimes. 

Commencons par les deux les plus faciles : 
string TrouverAdresse ( list<Employe> emp, string nom ) 



© copyright Editions Eyrolles 



20 



Programmation generique avec la bibliotheque standard C++ 



Au lieu d'etre passes par valeur, ces deux parametres devraient clairement etre 
passes par references constantes (respectivement const iist<Empioye>& et const 
strings), un passage par valeur provoquant la creation de deux objets temporaires 
penalisants en terme de performance et tout a fait inutiles. 



Recommandation 

Passez les objets par reference constante (consts) plutot que par valeur. 



Le troisieme objet temporaire est cree dans la condition de terminaison de la boucle : 

for( /*...*/ ; i != emp.end(); /*...*/ ) 

La fonction end() du conteneur list renvoie une valeur (c'est d'ailleurs le cas 
pour la majorite des conteneurs standards). Par consequent, un objet temporaire est 
cree et compare a i lors de chaque boucle. C'est parfaitement inefficace et inutile, 
d'autant plus que le contenu de emp ne varie pas pendant 1' execution de la boucle : il 
serait done preferable de stacker la valeur de emp . end ( ) dans une variable locale 
avant le debut de la boucle et d'utiliser cette variable dans 1' expression de la condition 
de fin. 



Recommandation 

Ne recreez pas plusieurs fois inutilement un objet dont la valeur ne change pas. Stockez-le 
plutot dans une variable locale que vous reutiliserez. 



Passons maintenant a un cas plus difficile a reperer : 

for ( /*...*/ ; i++ ) 

L'emploi de l'operateur de post-incrementation provoque l'utilisation d'un objet 
temporaire. En effet, contrairement a l'operateur de pre-incrementation, l'operateur de 
post-incrementation doit memoriser dans une variable temporaire la valeur « avant 
incrementation », afin de pouvoir la retourner a 1' appelant : 

const T T : : operator ++( int ) () 
{ 

T old ( *this ) ; // Memorisation de la valeur originale 
++*this; 

// Toujours implementer la post-incrementation 
// en fonction de la pre-incrementation. 

return old; / / Renvoi de la valeur originale 

} 

II apparait ici clairement que l'operateur de post-incrementation est moins efficace 
que l'operateur de pre-incrementation : le premier fait non seulement appel au second, 
mais doit egalement stacker et renvoyer la valeur originale. 
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Recommandation 

Afin d'eviter tout risque de divergence dans votre code, implementez systematiquement 
I'operateur de post-incrementation en fonction de I'operateur de pre-incrementation. 



Dans notre exemple, la valeur originale de i avant incrementation n'est pas utilisee : 
il n'y a done aucune raison d'utiliser la post-incrementation plutot que la pre-incremen- 
tation. Signalons, au passage, que de nombreux compilateurs remplacent souvent de 
maniere implicite et a titre d' optimisation, la post-incrementation par une pre-incremen- 
tation, lorsque cela est possible (voir plus loin le paragraphe consacre a ce sujet). 



Recommandation 

Reservez I'emploi de la post-incrementation aux cas ou vous avez besoin de recuperer la 
valeur originale de la variable avant incrementation. Dans tous les autres cas, preferez la pre- 
incrementation. 



if ( *i == nom ) 

Cette instruction nous indique que la classe Employe dispose soit d'un operateur 
de conversion vers le type string, soit d'un constructeur de conversion prenant une 
variable de type string en parametre. Dans un cas comme dans l'autre, ceci provoque 
la creation d'un objet temporaire afin de permettre l'appel d'une fonction opera- 
tor== o comparant des strings (si Employe a un operateur de conversion) ou des 
Employes (si Employe a un constructeur de conversion). 

Notons que le recours a cet objet temporaire peut etre evite si on fournit une fonc- 
tion operator==o prenant un operande de type string et un autre operande de type 
Employe (solution peu elegante) ou bien si Employe implemente une conversion vers 
une reference de type strings (solution preferable). 



Recommandation 

Prenez garde aux objets temporaires crees lors des conversions implicites. Pour les eviter 
au maximum, evitez de doter vos classes d'operateurs de conversion et specifiez I'attribut 
explicit pour les constructeurs susceptibles de realiser des conversions. 



return i->addr; 
// (ou) 

return ""; 

Ces instructions return provoquent chacune la creation d'un objet temporaire de 

type string. 

II serait techniquement possible d'eviter la creation de ces objets en ayant recours 
a la creation d'une variable locale : 

string ret; // Par defaut, vaut "" 
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if ( *i == nom ) 
{ 

ret = i->adresse; 

} 

return ret; 

Seulement, est-ce interessant en terme de performance ? 

Si cette deuxieme version peut paraitre plus claire, elle n'est pas necessairement 
plus efficace a la compilation : ceci depend du compilateur que vous utilisez. 

Dans le cas ou 1' employe serait trouve et son adresse renvoyee, nous avons, dans la 
premiere version, une construction « de copie » d'un objet string et, dans la seconde 
version, une construction par defaut suivi d'une affectation. 

En pratique, la premiere version « deux return » s'avere plus rapide 1 que la version 
« variable locale ». II n'est done ici pas souhaitable de supprimer les objets temporaires. 

string TrouverAdresse ( /* ... */) 

L'emploi d'un retour par valeur provoque la creation d'un objet temporaire. Ce 
dernier pourrait, estimez-vous, etre supprime grace a l'emploi d'un type reference 
(strings) en valeur de retour... Erreur ! Ceci signifierait, dans notre exemple, ren- 
voyer une reference vers une variable locale a la fonction ! A Tissue de l'execution de 
TrouverAdresse, cette reference ne serait plus valide et son utilisation provoquerait 
immanquablement une erreur a l'execution. 



Recommandation 

Ne renvoyez jamais une reference vers une variable locale a une fonction ! 



Pour etre honnete, il y a une technique possible permettant de renvoyer une refe- 
rence valide et d'eviter, par la-meme, la creation d'un objet temporaire. Cela consiste 
a avoir recours une variable locale statique : 

const strings 

TrouveAdresse ( /* emp et nom passes par reference */ ) 
{ 

for( /* ... */ ) 
{ 

if ( i->nom==nom ) 
{ 

return i->adresse; 

} 

} 

static const string vide; 
return vide; 

) 



1. Des tests effectues sur un compilateur tres repandu du marche ont prouve que la pre- 
miere version est de 5 % a 40 % plus rapide (en fonction du degre d' optimisation) 
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Si l'employe est trouve, on renvoie une reference vers une variable string membre 
d'un objet Employe contenu dans la liste. Cette solution n'est ni tres elegante ni tres sure, 
car elle repose sur le fait que F appelant soit bien au courant de la nature et de la duree de 
vie de l'objet reference. Par exemple, le code suivant provoquera une erreur : 

strings a = TrouverAdresse ( emp, "Jean Dupont" ); 

emp . clear ( ) ; 

cout << a; // Erreur ! 

L'emploi d'une reference non valide ne provoque pas systematiquement une 
erreur a 1' execution : cela depend du contexte du programme, de votre chance... ceci 
rend ce type de bogue d'autant plus difficile a diagnostiquer. 

Une erreur de ce type couramment repandue est 1' utilisation d'iterateurs invalides 
par une operation effectuee sur le conteneur qu'ils permettent de manipuler (voir le 
probleme n° 1 a ce sujet). 

Voici, pour finir, une nouvelle implementation de la fonction TrouverAdresse, 
dans laquelle tous les objets temporaires superflus ont ete supprimes (d'autres optimi- 
sations auraient ete possibles, on ne s'y interessera pas dans ce probleme). Remar- 
quons que comme iist<Empioye> est dorenavant passe en parametre constant, il faut 
utiliser des iterateurs constants. 

string TrouverAdresse ( const list<Employee>& emp, 

const strings nom ) 

{ 

list<Employe> : : const_iterator end ( emp. end () ); 
for ( list<Employe> : : const_iterator i = emp. begin () ; 

i != end; 

++i ) 

{ 

if ( i->nom == nom ) 
{ 

return i->adresse; 

} 

} 

return ""; 

} 

Optimisation de la post-incrementation 
par les compilateurs 

Lorsque que vous employez un operateur de post-incrementation sans utiliser la valeur 
originale, vous perdez en efficacite par rapport a l'emploi d'une simple pre-incrementation. 

Le compilateur est-il autorise, a titre d'optimisation, a remplacer une post-incre- 
mentation non justifiee par une pre-incrementation ? 

La reponse est en general non, sauf dans certains cas bien precis, comme les types 
standard predefinis int et complex que le compilateur peut traiter d'une maniere 
specifique. 
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Pour les types non predefinis, le compilateur n'est par defaut pas autorise a effec- 
tuer ce type d' optimisation, car il ne maitrise pas a priori la syntaxe d'utilisation d'une 
classe implementee par un developpeur. A la limite, rien ne permet de presumer du 
fait que les operateurs de post-incrementation et pre-incrementation realisent la meme 
operation, a la valeur retournee pres (bien qu'evidemment, il soit plus que souhaitable 
que cette situation totalement incoherente soit evitee, sous peine de rendre tres dange- 
reuse l'utilisation de la classe en question). 

II y a neanmoins une solution pour forcer 1' optimisation : elle consiste a imple- 
menter en-ligne (inline) l'operateur de post-incrementation (lequel doit, rappelons- 
le, faire appel a l'operateur de pre-incrementation). Ceci aura pour effet de rendre 
visibles les objets temporaires dans le code appelant, permettant ainsi au compilateur 
de les supprimer dans le cadre classique des optimisations. 

Cette derniere solution n'est pas recommandee, l'emploi de fonctions en-ligne n'etant 
jamais ideal. La meilleure option consiste evidemment a prendre l'habitude d'utiliser sys- 
tematiquement la pre-incrementation lorsque la recuperation de la valeur originale n'est 
pas requise. 



Pb n° 7. Algorithmes standards Difficulte : 5 



La capacite a reutiliser I'existant fait partie des qualites requises pour un bon developpeur. La 
bibliotheque standard regorge de fonctionnalites tres utiles, qui ne sont malheureusement pas 
assez souvent exploiters. Pour preuve, nous allons voir comment il est possible d'ameliorer le 
programme du probleme precedent en reutilisant un algorithme existant. 



Reprenons le code du probleme precedent : 

string TrouverAdresse ( list<Employe> emp, string nom ) 
{ 

f or ( list<Employe> :: iterator i = emp . begin () ; 
i ! = emp . end ( ) ; 
i++ ) 

{ 

if ( *i == nom ) 
{ 

return i->adresse; 

} 

} 

return ""; 

} 

Peut-on simplifier cette fonction en faisant appel a des elements de la bibliotheque 
standard ? Quels avantages peut-on retirer de cette modification ? 
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Solution 



L'emploi de l'algorithme standard find ( ) permet d'eliminer la boucle de parcours 
des elements (il aurait egalement ete possible d'utiliser la fonction f ind_if) : 



string FindAddr ( list<Employee> emps, string name ) 
{ 

list<Employee> :: iterator i( 

find( emps . begin () , emps.end(), name ) 
) ; 

if ( i != emps. end () ) 

{ 

return i->addr; 

} 

return ""; 



Cette implementation est plus simple et plus efficace que 1' implementation origi- 
nale. 



Recommandation 

Reutilisez le code existant - surtout celui de la bibliotheque standard. C'est plus rapide, 
plus facile et plus sur. 



On a toujours interet a reutiliser les fonctionnalites de la bibliotheque standard 
plutot que de perdre du temps a reecrire des algorithmes ou des classes existantes. Le 
code de la bibliotheque standard a toutes les chances d'etre bien plus optimise que le 
notre et de comporter moins d'erreurs - en effet il a ete developpe depuis longtemps et 
deja utilise par un grand nombre de developpeurs. 

En combinant l'emploi de find ( ) et la suppression des objets temporaires vue lors 
du probleme precedent, nous obtenons une fonction largement optimisee : 

string TrouverAdresse ( const list<Employe>& emp, 

const strings nom ) 

{ 

list<Employee> : : const_iterator i ( 
find( emp.begin(), emp . end ( ) , nom ) 
) ; 

if ( i ! = emp . end ( ) ) 

{ 

return i->adresse; 

} 

return ""; 

} 
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Commencons par un bref historique des publications qui ont inspire ce chapitre. 

En 1994, Tom Cargill publia un article intitule « Gestion des exceptions : une 
fausse impression de securite » (Cargill94) 1 , dans lequel il presenta plusieurs exem- 
ples de code pouvant se comporter de maniere incorrecte en presence d'exceptions. II 
soumit egalement a ses lecteurs un certain nombre de problemes, dont certains reste- 
rent sans solution valable pendant plus de trois ans, mettant ainsi en evidence le fait 
qu'a l'epoque, la communaute C++ maitrisait imparfaitement la gestion des excep- 
tions. 

II fallut attendre 1997 et la publication de « Guru of the Week n° 8 » sur le groupe 
de discussion Internet comp.lang. C++. moderated pour que soit enfin fournie une solu- 
tion complete au probleme de Cargill. Cet article, qui eut un certain retentissement, fit 
l'objet, un an plus tard, d'une seconde parution dans les numeros de septembre, 
novembre et decembre 1998 de « C+ + Report ». Cette seconde version, adaptee pour 
etre conforme aux dernieres evolutions du standard C++, ne presentait pas moins de 
trois solutions completes au probleme initial (tous ces articles seront repris prochaine- 
ment dans un ouvrage a paraitre prochainement : C++ Gems II [MartinOO]). 

Au debut de l'annee 1999, Scott Meyers proposa dans « Effective C++ CD » 
(Meyers99) une version retravaillee du probleme original de Cargill, enrichie d' arti- 
cles issus de ses autres ouvrages Effective C++ etMore Effective C+ + . 

Nous presentons dans ce chapitre une synthese de toutes ces publications, enri- 
chies notamment par Dave Abrahams et Greg Colvin qui sont, avec Matt Austern, les 
auteurs de deux rapports soumis au Comite de Normalisation C++ ayant conduit a la 
nouvelle version de la bibliotheque standard, mieux adaptee a la gestion des excep- 
tions. 



1. Disponible sur Internet a l'adresse http://cseng.awl.com/bookdetail.qry?ISBN=0-201- 
63371-X&ptype=636. 
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PB N° 8. ECRIRE DU CODE ROBUSTE AUX 

exceptions (1 re partie) Difficulty : 7 



La gestion des exceptions est, avec I'utilisation des modeles, I'une des fonctionnalites les plus 
puissantes du C++ ; c'est aussi I'une des plus difficiles a maTtriser, notamment dans le contexte 
de modeles de classe ou de fonction, ou le developpeur ne connait a I'avance ni les types mani- 
pules, ni les exceptions qui sont susceptibles de se produire. 

Dans ce probleme, nous etudierons, par l'intermediaire d'un exemple mettant en 
oeuvre exceptions et modeles de classe, les techniques permettant d'ecrire du code se 
comportant correctement en presence d'exceptions. Nous verrons egalement comment 
realiser des conteneurs propageant correctement toutes les exceptions vers 1' appelant, 
ce qui est plus facile a dire qu'a faire. 

Nous repartirons de 1' exemple initial soumis par Cargill : un conteneur de type 
« Pile » (stack) dans lequel l'utilisateur peut ajouter (push) ou retirer (Pop) des ele- 
ments. Au fur et a mesure de l'avancement du chapitre, nous ferons evoluer progressi- 
vement ce conteneur, le rendant de plus en plus apte a gerer correctement les 
exceptions, en diminuant progressivement les contraintes imposees sur le type 
t contenu. Nous aborderons notamment le point particulier des zones memoires 
allouees dynamiquement, particulierement sensibles aux exceptions. 

Ceci nous permettra, au passage, de repondre aux questions suivantes : 

■ Quels sont les differents degres de qualite possibles dans la gestion des exceptions ? 

■ Un conteneur generique peut-il (et doit-il) propager toutes les exceptions lancees 
par le type contenu vers le code appelant ? 

■ Les conteneurs de la bibliotheque standard se comportent-ils correctement en pre- 
sence d'exceptions ? 

■ Le fait de rendre un conteneur capable de gerer correctement les exceptions a-t-il 
un impact sur son interface publique ? 

■ Les conteneurs generiques doivent-ils utiliser des specificateurs d' exception 
(throw) au niveau de leur interface ? 

Nous presentons ci-dessous la declaration du conteneur stack tel qu'il a ete initia- 
lement propose par Cargill. Le but du probleme est de voir s'il se comporte correcte- 
ment en presence d'exceptions ; autrement dit, de s'assurer qu'un objet stack reste 
toujours dans un etat valide et coherent, quelles que soient les exceptions generees par 
ses fonctions membres, et que ces exceptions sont correctement propagees au code 
appelant - le seul capable de les gerer etant donne que la definition du type contenu 
(t) n'est pas connue au moment de 1' implementation de stack. 

template <class T> class Stack 
{ 

public : 
Stack ( ) ; 
-Stack ( ) ; 
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/*...*/ 
private : 

T* v_; // Pointeur vers une zone memoire 

// allouee dynamiquement 
size_t vsize_; // Taille totale de la zone memoire 
size_t vused_; // Taille actuellement utilisee 



Implementez le constructeur par defaut et le destructeur de stack, en vous assu- 
rant qu'ils se comportent correctement en presence d' exceptions, en respectant les 
contraintes enoncees plus haut. 



II est clair que le point le plus sensible concernant la classe stack est la gestion de 
la zone memoire allouee dynamiquement. Nous devons absolument nous assurer 
qu'elle sera correctement liberee si une exception se produit. Pour 1' instant, nous 
considerons que les allocations / deallocations de cette zone sont gerees directement 
depuis les fonctions membres de stack. Dans un second temps, nous verrons une 
autre implementation possible, faisant appel a une classe de base privee. 



Constructeur par defaut 

Voici une proposition d' implementation pour le constructeur par defaut : 

// Ce constructeur se comportera-t-il correctement 
// en presence d' exceptions ? 

template<clas s T> 
Stack<T> : : Stack ( ) 
: v_(0), 

vsize_ ( 10 ) , 

vused_(0) // Au depart, rien n'est utilise 

{ 

v_ = new T[vsize_]; // Allocation initiate 

} 

Ce constructeur se comportera-t-il correctement en presence d' exceptions ? Pour 
le savoir, identifions les fonctions susceptibles de lancer des exceptions et voyons ce 
qui se passerait dans ce cas-la ; toutes les fonctions doivent etre prises en compte : 
fonctions globales, constructeurs, destructeurs, operateurs et autres fonctions mem- 
bres. 

Le constructeur de stack affecte la valeur 10 a la variable membre vsize_, puis 
alloue dynamiquement un tableau de vsize_ objets de type t. L'instruction « new 
T[vsize_] » appelle l'operateur global ::new (ou l'operateur new redefini par la 
classe t, s'il y en existe un) et le constructeur de t, et ceci autant de fois que necessaire 
(10 fois, en 1' occurrence). Chacun de ces operateurs peut echouer : d'une part, l'ope- 
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rateur new peut lancer une exception bad_aiioc, d' autre part, le constructeur de t peut 
lancer n'importe quelle exception. Neanmoins, dans les deux cas, nous sommes assu- 
res que la memoire allouee sera correctement desallouee par un appel a l'operateur 
deiete[] adequat, et que, par consequent, 1' implementation proposee ci-dessus se 
comportera parfaitement en presence d'exceptions. 

Ceci vous parait un peu rapide ? Rentrons un petit peu dans le detail : 

1. Toutes les exceptions eventuelles sont correctement transmises a l'appelant. 

Dans ce constructeur, nous n' interceptons aucune exception (pas de bloc catch) : 
nous sommes done assures que si l'instruction « new t [vsize_] » genere une excep- 
tion, celle-ci sera correctement propagee au code appelant. 



Recommandation 

Une fonction ne doit pas bloquer une exception : elle doit obligatoirement la traiter et/ou 
la transmettre a l'appelant. 



2. II n'y a pas de risque de fuites memoires. Detaillons en effet ce qui se passe en cas 
de generation d' exception : si l'operateur new ( ) lance une exception bad_aiioc, comme 
le tableau d'objets t n'a pas encore ete alloue, il n'y a done pas de risque de fuite ; si la 
construction d'un des objets t alloue echoue, le destructeur de stack est automatique- 
ment appele (du fait qu'une exception a ete generee au cours de l'execution de 
stack : : stack), ce qui a pour effet d'executer 1'instruction delete [ ] , laquelle effectue 
correctement la destruction et la deallocation des objets t ayant deja ete alloues. 

On fait ici l'hypothese que le destructeur de t ne lance pas d'exceptions, ce qui 
aurait pour effet catastrophique d'appeler la fonction terminate o en laissant toutes 
les ressources allouees. Nous argumenterons cette hypothese lors du probleme n° 16 
« Les dangers des destructeurs lancant des exceptions ». 

3. Les objets restent toujours dans un etat coherent, meme en cas d'exceptions. Cer- 
tains pourraient arguer que si une exception se produit lors de 1' allocation du tableau dans 
stack: : stack (), la variable membre vsize_ se retrouve initialisee avec une valeur de 10 
alors que le tableau correspondant n'existe pas, et que, done, nous nous retrouvons dans un 
etat incoherent. En realite, cet argument ne tient pas car la situation decrite ci-dessus ne 
peut pas se produire : en effet, a partir du moment ou une exception se produit dans le 
constructeur d'un objet, cet objet est automatiquement detruit et peut done etre considere 
comme « mort-ne ». II n'y a done aucun risque de se retrouver avec un objet stack exis- 
tant dans un etat incoherent. 



Recommandation 

Assurez-vous que votre code se comporte correctement en presence d'exceptions. En par- 
ticulier, organisez votre code de maniere a desallouer correctement les objets et a laisser les don- 
nees dans un etat coherent, meme en presence d'exceptions. 
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Pour finir, signalons qu'il y a une autre maniere, plus elegante, d'ecrire le meme 
constructeur : 

template<class T> 
Stack<T> : : Stack ( ) 
: v_(new T [10] ) , 

vsize_ ( 10 ) , 

vused_ ( 0 ) 

{ 
} 

Cette deuxieme version, equivalente a la premiere en terme de fonctionnalites, est 
preferable car elle initialise tous les membres dans la liste d' initialisation du 
constructeur, ce qui est une pratique recommandable. 



Destructeur 

L' implementation du destructeur est facile a partir du moment ou nous faisons une 
hypothese simple : 

template<class T> 
Stack<T> : : -Stack ( ) 
{ 

delete [] v_; // Ne peut pas lancer d' exception 

} 

Pour quelle raison « delete [] v » ne risque-t-elle pas de lancer d'exception ? 
Cette instruction appelle t : : ~t pour chacun des objets du tableau, puis appelle l'ope- 
rateur delete [ ] ( ) pour desallouer la memoire. 

La norme C++ indique qu'un operateur delete no ne peut pas lancer d' excep- 
tions, comme le confirme la specification des prototypes autorises pour cette fonc- 
tion 

void operator delete [] ( void* ) throw (); 

void operator delete!] ( void*, size_t ) throw () ; 

Par consequent, la seule fonction susceptible de lancer une exception est le des- 
tructeur de t. Or, nous avons justement fait precedemment l'hypofhese que cette 
fonction t: :~to ne lancait pas d' exceptions. Nous aurons l'occasion de demontrer, 
plus loin dans ce chapitre, que ce n'est pas une hypothese deraisonnable. Cela ne 
constitue pas, en tous cas, une contrainte trop forte sur t. Nous allons simplement 
admettre dans un premier temps, qu'il ne serait pas possible de realiser un programme 
correct allouant et desallouant dynamiquement des tableaux d'objets si le destructeur 



1 . Techniquement parlant, rien de ne vous empeche d'implementer un operateur delete [ ] 
susceptible de lancer des exceptions ; ce serait neanmoins extremement dommageable a 
la qualite de vos programmes. 



// Allocation initiale 

// Au depart, rien n'est utilise 



© copyright Editions Eyrolles 



32 Gestion des exceptions 



des objets alloues est susceptible de lancer des exceptions 1 . Nous en detaillerons les 
raisons plus loin dans ce chapitre. 



Recommandation 

Assurez-vous que tous les destructeurs et les operateurs delete o (ou delete [] ()) que 
vous implementez ne laissent pas remonter d'exceptions ; ils ne doivent pas generer d'excep- 
tion eux-memes ni laisser remonter une exception recue d'un niveau inferieur. 



PB N° 9. ECRIRE DU CODE ROBUSTE 

AUX EXCEPTIONS (2 e partie) DlFFICULTE I 8 



Les cas du constructeur et du destructeur de stack ( ) etant regies, nous passons, dans ce pro- 
bleme, au constructeur de copie et a I'operateur d'affectation, pour lesquels I'implementation 
sera legerement plus complexe a realiser. 



Repartons de l'exemple du probleme precedent : 

template <class T> class Stack 
{ 

public : 
Stack ( ) ; 
-Stack () ; 

Stack (const Stacks); 

Stacks operator= (const Stacks); 

/*...*/ 



private : 

T* v_; // Pointeur vers une zone memoire 

// allouee dynamiquement 
size_t vsize_; // Taille totale de la zone memoire 
size_t vused_; // Taille actuellement utilisee 



Implementez le constructeur de copie et I'operateur d'affectation de stack, en 
vous assurant qu'ils se comportent correctement en presence d'exceptions. Veillez 
notamment a ce qu'ils propagent toutes les exceptions recues vers le code appelant et 
laissent, quoi qu'il arrive, l'objet stack dans un etat coherent. 



1. C'est de toute fajon une bonne habitude de programmation de ne pas lancer des excep- 
tions depuis un destructeur ; l'ideal etant d'adjoindre la specification throw ( ) a chaque 
destructeur implemented 



© copyright Editions Eyrolles 



Pb n° 9. Ecrire du code robuste aux exceptions (2 e partie) 



33 



Solution 



Nous fonderons 1' implementation du constructeur de copie et de l'operateur 
d' affectation sur une seule et meme fonction utilitaire NewCopy ( ) , capable de realiser 
une copie (et eventuellement, au passage, une reallocation avec augmentation de 
taille) d'un tableau dynamique d'objets t. Cette fonction prend en parametre un poin- 
teur vers un tableau existant (src), la taille du tableau existant (srcsize) et du tableau 
cible (destsize) ; elle renvoie a l'appelant un pointeur vers le tableau nouvellement 
alloue (dont l'appelant garde desormais la responsabilite). Si une exception se produit 
au cours de l'execution de NewCopy, toutes les zones memoires temporaires sont cor- 
rectement desallouees et 1' exception est correctement propagee a l'appelant. 

template<class T> 

T* NewCopy ( const T* src, 

size_t srcsize, 

size_t destsize ) 

{ 

assert ( destsize >= srcsize ) ; 
T* dest = new T [destsize]; 
try 

{ 

copy ( src, src+srcsize, dest ) ; 

} 

catch (...) 
{ 

delete[] dest; / / Ne peut pas lancer d' exception 
throw; // Relance 1' exception originate 

} 

return dest; 

} 

Analysons cette fonction : 

1. La premiere source potentielle d'exception est l'instruction « new 
t [destsize] » : une exception de type bad_aiioc peut se produire lors de l'appel a 
new ou bien une exception de type quelconque peut se produire lors de l'appel du 
constructeur de t ; dans les deux cas, rien n'est alloue et la fonction se termine en ne 
laissant aucune fuite memoire et en propageant correctement les exceptions au niveau 
superieur. 

2. La deuxieme source potentielle d'exception est la fonction t : : operator= ( ) , appe- 
lee par la fonction copy ( ) : si elle genere une exception, celle-ci sera intercepted puis 
relancee par le bloc catch) }, lequel detruit au passage le tableau dest precedemment 
alloue ; ceci assure un comportement correct (pas de fuite memoire, exceptions propa- 
gees a l'appelant). Nous faisons ici neanmoins l'hypothese importante que la fonction 
T: :operator=o est implementee de telle sorte qu'en cas de generation d'exception, 
l'objet cible (*dest, dans notre cas) puisse etre detruit sans dommage (autrement dit, 
qu'il n'ait pas ete deja partiellement detruit, ce qui provoquerait une erreur a l'execu- 
tion de « delete [ ] dest »)'. 
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3. Si 1' allocation et la copie ont reussi, le pointeur du tableau cible est renvoye a 
l'appelant (qui en devient responsable) par l'instruction « return dest », qui ne peut 
pas generer d' exception (copie d'une valeur de pointeur). 

Constructeur de copie 

Nous obtenons ainsi facilement une implementation du constructeur de copie de 

Stack, basee SUrNewCopyO : 

template<class T> 

Stack<T> :: Stack ( const Stack<T>& other ) 
: v_(NewCopy( other. v, 

other . vsize, 
other .vsize) ) , 
vsize_ (other . vsize_) , 
vused_ (other . vused_) 

{ 
} 

La seule source potentielle d'exceptions est NewCopy, pour laquelle on vient de 
voir qu'elle les gere correctement. 



Operateur d 'affectation 

Passons maintenant a l'operateur d' affectation : 

template<class T> 
Stack<T>& 

Stack<T> : : operator= ( const Stack<T>& other ) 
{ 

if( this != Sother ) 
{ 

T* v_new = NewCopy ( other. v_, 

other . vsi ze_, 

other. vsize_ ); 
delete [] v_; / / Ne peut pas lancer d' exception 
v_ = v_new; // Prise de controle du nouveau tableau 
vsize_ = other . vsi ze_; 
vused_ = other . vused_; 

} 

return *this; // Pas de risque d' exception 
// (pas de copie de l'objet) 

} 

Cette fonction effectue un test preliminaire pour eviter l'auto affectation, puis 
alloue un nouveau tableau, utilise ensuite pour remplacer le tableau existant ; la seule 



1. Nous verrons plus loin une version amelioree de stack ne faisant plus appel a T : : ope- 
rator ( ) . 
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instruction susceptible de lancer une exception est la fonction New copy ( ) . Si une 
exception se produit, l'etat de l'objet est inchange et l'exception est correctement 
transferee a 1' appelant. 

Cet exemple permet d'illustrer la technique generate a utiliser pour une gestion 
correcte des exceptions. 



Recommandation 

Lorsque vous implementez une fonction destinee a realiser une certaine operation, sepa- 
rez les instructions effectuant I'operation elle-meme (susceptibles de generer une exception), du 
code realisant la validation de cette operation, constitue d'instructions unitaires (ne risquant pas 
de generer des exceptions). 



Pb n° 1 0. Ecrire du code robuste aux exceptions 

(3 e partie) Difficulte : 9 1/2 



Passons maintenant a la derniere partie de I'implementation de notre conteneur stack, la 
moins facile des trois... 

Cette fois encore, il s'agit d'ajouter des nouvelles fonctions membres au modele 
de classe stack : 

template <class T> class Stack 
{ 

public : 
Stack () ; 
-Stack ( ) ; 

Stack (const Stacks); 

Stacks operator= (const Stacks); 

size_t Count () const; 

void Push (const TS) ; 

T Pop(); // Lance une exception si la pile est vide 

private : 

T* v_; // Pointeur vers une zone memoire 

// allouee dynamiquement 
size_t vsize_; // Taille totale de la zone memoire 
size_t vused_; // Taille actuellement utilisee 

}; 

Implementez les fonctions membres count ( ) , permettant de recuperer la taille de 
l'espace memoire utilise par la pile, Push ( ) , permettant d'ajouter un element a la pile, 
et Pop ( ) , permettant de retirer 1' element le plus recemment ajoute a la pile (cette fonc- 
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tion lancera une exception si la pile est vide). Bien entendu, ces trois fonctions doi- 
vent se comporter correctement en presence d' exceptions ! 



(j- Solution 

La fonction Count() 

Cette fonction est, de loin, la plus facile a implementer : 

template<class T> 

size_t Stack<T> :: Count ( ) const 

{ 

return vused_; / / Ne peut pas lancer d' exception 

} 

count ( ) renvoie la valeur d'un type predefini. Aucun probleme. 



La fonction Push() 

Pour cette fonction, nous allons employer une technique similaire a celle utilisee 
pour 1' implementation du constructeur de copie et de Foperateur d'affectation : 

template<class T> 

void Stack<T> : : Push ( const T& t ) 
{ 

if ( vused_ == vsize_ ) // Si necessaire, on augmente 
{ // la taille du tableau 

size_t vsizejew = vsize_*2+l; // Facteur arbitraire 

T* v_new = NewCopy ( v_, vsize_, vsizejew ) ; 

delete[] v_; / / Ne peut pas lancer d' exception 

v_ = v_new; // Prise de controle du nouveau tableau 

vsize_ = vsizejew; 

} 

v_[vused_] = t; 
++vused_; 

} 

La fonction commence par executer, si necessaire, un bloc d' instructions destinees 
a augmenter la taille du tableau : on fait d'abord appel a la fonction NewCopy ( ) - si 
cette fonction genere une exception, Fetat de l'objet stack reste inchange et Fexcep- 
tion est correctement transmise a 1' appelant - puis a un ensemble d'instructions uni- 
taires effectuant la prise en compte de 1' operation. Ce premier bloc se comporte done 
correctement en presence d' exceptions. 

Cette operation de reallocation (eventuellement) effectuee, la fonction copie 1' ele- 
ment regu en parametre dans le tableau interne, puis incremente l'indicateur de taille 
utilise. Ainsi, si Foperation de copie echoue, l'indicateur de taille n'est pas modifie. 
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P3 



Recommandation 



Lorsque vous implementez une fonction destinee a realiser une certaine operation, sepa- 
rez les instructions effectuant I'operation elle-meme (susceptibles de generer une exception), du 
code realisant la validation de cette operation, constitue d'instructions unitaires (ne risquant pas 
de generer des exceptions). 



La fonction Pop() 

Contrairement aux apparences, cette fonction va etre relativement complexe a 
securiser. En effet, que penser de 1' implementation ci-dessous, celle qui viendrait 
naturellement a 1' esprit ? 

// Est-ce vraiment une bonne implementation ?? 

template<class T> 
T Stack<T>: :Pop() 
{ 

if ( vused_ == 0 ) 
{ 

throw "Erreur : la pile est vide"; 

} 

else 
{ 

T result = v_ [ vused_-l ] ; 
— vused_; 
return result; 

} 

} 

Si la pile est vide, une exception est generee et transmise a 1' appelant ; c'est cor- 
rect. Dans les autres cas, on copie la valeur du dernier element du tableau dans une 
variable locale result, que Ton renvoie a Fappelant, apres avoir diminue la valeur de 
la taille utilisee. Si la copie de l'objet v[vused-i] vers t provoque une exception, 
alors la taille de la pile n'est pas modiriee et 1' exception est transmise a 1' appelant ; 
c'est correct egalement. 

Finalement, cette fonction semble done correctement implementee. En realite, ce 
n'est pas le cas ; en effet, considerons le code client suivant, qui utilise une variable 

stack<string> nommee s : 

string sl(s.PopO); 
string s2; 
s2 = s . Pop ( ) ; 

Si une exception se produit lors de l'appel a s .Pop o a la construction de l'objet 
si, cet objet restera dans un etat incoherent (non initialise). Pire, si une exception se 
produit lors de l'appel a Pop ( ) dans l'instruction s2=s .Pop ( ) , non seulement l'objet 
s2 ne sera pas correctement initialise, mais, dans certains cas, il peut se produire des 
fuites memoires irrecuperables. En effet, cette instruction fait appel a un objet tempo- 
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raire, retourne par la fonction 1 , dans lequel est copie l'objet retire de la pile, et qui sera 
a son tour copie dans s2. Si une exception se produit, lors de la copie de l'objet tem- 
poraire, le pointeur vers l'objet t venant d'etre depile sera irremediablement perdu, 
laissant une zone memoire impossible a desallouer. Ce code ne se comporte done pas 
correctement en presence d' exceptions. Neanmoins, il faut noter que l'utilisateur de 
stack n'avait aucune possibilite d'implementer un code correct et que le probleme est 
inherent a la conception meme de la fonction stack : : Pop ( ) et au fait qu'elle renvoie 
un objet t par valeur, ce qui est la source de nos soucis (voir egalement le probleme 
n° 19 sur conception des fonctions et gestion des exceptions). 

Le principal enseignement de cet exemple est que la gestion correcte des excep- 
tions n'est pas un detail d' implementation, mais un element devant etre pris en compte 
des la conception de la classe. 



Erreur a eviter 

Ne considerez pas la gestion des exceptions comme un detail d'implementation. C'est au 
contraire un element primordial a prendre en compte des la conception de vos programmes. 



Deuxieme version de la fonction Pop() 

Voici une seconde proposition d'implementation pour la fonction Pop ( ) , obtenue 
suite a un petit nombre de changements 2 : 

template<class T> 

void Stack<T> : : Pop ( T& result ) 

{ 

if ( vused_ == 0 ) 
{ 

throw "Erreur : la pile est vide"; 

} 

else 
{ 

result = v_ [vused_-l ] ; 
--vused_; 

} 

} 



1. II est possible que certains compilateurs, a des fins d' optimisation, n'aient pas recours a 
un objet temporaire dans ce type de situation. Neanmoins, pour etre portable, un code 
doit se comporter correctement, qu'il y ait un objet temporaire ou non. 

2. Plus exactement, suite au nombre minimal de changements possibles. La solution 
consistant a implementer une fonction PopO renvoyant une reference vers l'objet T 
depile n'est pas viable, car cela signifierait avoir une reference vers un objet contenu 
physiquement dans stack mais dont stack n'a plus la responsabilite, ce qui est dange- 
reux (stack pouvant tout a faire decider de desallouer l'objet correspondant, vu qu'il ne 
fait plus partie de la pile) 
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Cette implementation assure que l'objet depile arrive correctement au niveau du 
code appelant, sauf en cas de pile vide, bien entendu. 

II subsiste neanmoins un defaut dans cette version : la fonction Pop o a deux res- 
ponsabilites : depiler le dernier element de la pile et le renvoyer a 1' appelant. II serait 
preferable de separer ces deux roles. 



Recommandation 

Efforcez-vous de toujours decouper votre code de maniere a ce que chaque unite d'execu- 
tion (chaque module, chaque classe, chaque fonction) ait une responsabilite unique et bien 
definie. 



II serait preferable d' avoir deux fonctions distinctes, l'une renvoyant le dernier ele- 
ment de la pile (Top), l'autre le depilant (Pop). 

template<class T> 
T& Stack<T> : : Top ( ) 
{ 

if ( vused_ == 0 ) 
{ 

throw "Erreur : pile vide"; 

} 

return v_ [ vused_-l ] ; 

} 

template<class T> 
void Stack<T> : : Pop ( ) 
{ 

if ( vused_ == 0 ) 

throw "Erreur : pile vide"; 
else 

— vused_; 

} 

On remarque au passage que cette meme technique est utilisee par les conteneurs 
de la bibliofheque standard, dont les fonctions « Pop » (list : :pop_back, 
stack: :pop,...) ne permettent pas de recuperer la valeur venant d'etre depilee. Ce 
n'est pas un hasard; c'est, en realite, le seul moyen de se comporter correctement en 
presence d' exceptions. 

Les fonctions ci-dessus sont similaires aux fonctions membres top et pop du 
conteneur stacko de la librairie standard. La encore, il ne s'agit pas d'une coinci- 
dence. Pour que le parallele soit parfait, il faudrait rajouter deux fonctions membres a 
notre conteneur stacko : 
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template<class T> 

const T& Stack<T> : : Top ( ) const 

{ 

if ( vused_ == 0 ) 
{ 

throw "Erreur : pile vide"; 

} 

else 
{ 

return v_ [ vused_-l ] ; 

} 

} 

Version surcharged de la fonction Top ( ) renvoyant une reference constante vers le 
dernier element de la pile. 

template<class T> 

bool Stack<T> :: Empty ( ) const 

{ 

return ( vused_ ==0 ) ; 

} 

Fonction permettant de determiner si la pile est vide ou non. 

Nous obtenons ainsi un conteneur stacko dont l'interface publique est identique 
au stacko de la bibliotheque standard (il faut neanmoins noter que le stacko stan- 
dard est different puisqu'il sous-traite les fonctionnalites de conteneur a un objet 
interne, mais ce n'est qu'un detail d' implementation). 



Erreur a eviter 

Ne sous-estimez pas I'importance de la gestion des exceptions, qui doit etre prise en 
compte des la phase de specification d'un programme. II peut etre difficile, voire impossible, de 
realiser un programme se comportant correctement en presence d'exceptions a partir de clas- 
ses et fonctions mal concues. 



En particulier, comme nous venons de le voir, il est en general tres difficile 
d'ecrire du code correct en presence de fonctions effectuant deux taches a la fois. 

Nous etudierons plus loin dans ce chapitre un autre exemple classiquement gene- 
rateur de problemes lies aux exceptions : les constructeurs de copie et les operateurs 
d' affectation incapables de gerer correctement 1' auto- affectation (en fait ceux qui ont 
recours a un test preliminaire pour eviter 1' auto-affectation mais ne fonctionneraient 
pas correctement sans ce test). 
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Pb n° 11. Ecrire du code robuste aux exceptions 

(4 e partie) Difficulte : 8 



Ce probleme fait la synthese des trois problemes precedents et tente de degager des regies 
generales relatives a la gestion des exceptions. 



Nous disposons a present d'un conteneur stack<T> se comportant correctement en 
presence d' exceptions. 

Repondez le plus precisement possible aux questions suivantes : 

■ Quels sont les principaux elements garantissant le bon comportement d'un pro- 
gramme en presence d' exceptions ? 

■ Quels sont les contraintes imposees au type contenu (t) pour le fonctionnement 
correct du conteneur stack<T>? 




II est certain qu'il existe plusieurs manieres d' ecrire du code se comportant correc- 
tement en presence d'exceptions. On peut neanmoins degager les principes generaux 
suivants, initialement enonces par Dave Abrahams : 

■ Les zones memoires dynamiques doivent etre correctement desallouees en 
presence d'exceptions. Dans le cas de notre conteneur stack, ceci signifie que si 
une exception est lancee par un objet t contenu ou par toute autre operation effec- 
tuee au sein de stack, les objets alloues dynamiquement doivent etre correctement 
liberes afin de ne pas provoquer de fuites memoires. 

■ Toute operation echouant a cause d'une exception doit etre annulee. Autre - 
ment dit, une operation doit toujours etre realisee de maniere atomique (soit entie- 
rement effectuee, soit entierement annulee) et ne jamais laisser le programme dans 
un etat incoherent. C'est le type de semantique qui est couramment utilisee dans le 
contexte des bases de donnees sous les termes « validation ou 
annulation » (« commit ou rollback ») . Prenons Fexemple d'un client de stack 
appelant successivement la fonction Pop() pour recuperer une reference vers le 
dernier element de la pile, puis la fonction Push ( ) pour aj outer un element : si cette 
deuxieme fonction echoue a cause d'une exception, l'etat de 1' objet stack doit res- 
ter inchange et, en particulier, la reference obtenue par Pop o doit toujours etre 
valide. Pour plus d' informations a ce sujet, voir la documentation de la SGI 1 , une 
implementation specifique de la bibliotheque standard garantissant une gestion 
correcte des exceptions, realisee par Dave Abrahams (http://www.stlport.org/doc/ 
sgi_stl.html). 



1 . Silicon Graphics Implementation 
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Remarquons qu'en general, si le premier principe est respecte, il y a de fortes 
chances pour que le second le soit aussi, d'emblee 1 . Par exemple, dans le cas precis 
de notre conteneur stack, nous nous sommes concentres sur le fait d'obtenir une 
deallocation correcte des zones de memoire dynamique en cas d' exceptions et avons 
automatiquement obtenu un code verifiant pratiquement le second principe 2 . 

Dans certains cas, il peut etre utile d'exiger d'une fonction qu'elle ne lance 
d' exceptions dans aucun cas. II est parfois necessaire d' avoir recours a une contrainte 
de ce type arm d' assurer le comportement correct d'un programme, comme nous 
1' avons vu a 1' occasion du destructeur de stack. Nous reviendrons sur ce sujet dans la 
suite de ce chapitre. 



Recommandation 

Connaissez et appliquez les principes generaux garantissant le bon comportement d'un 
programme en presence d'exceptions. 



Concernant 1' implementation de stack, il est interessant de noter au passage que 
nous avons obtenu un modele de classe parfaitement robuste aux exceptions en ne fai- 
sant appel qu'a un seul bloc try/catch. Nous verrons plus loin une seconde version 
de stack, encore plus elegante, n'ayant, quant a elle, recours a aucune instruction 

try/ catch. 

Passons maintenant a la deuxieme question. Les contraintes imposees au type 
contenu (t) pour le fonctionnement correct du conteneur stack<T> sont les suivan- 
tes : 

■ existence d'un constructeur par defaut (necessaire pour la bonne compilation de 
l'instruction « new t [ . . . ] ») ; 

■ existence d'un constructeur de copie (dans le cas ou Pop retourne un objet par 
valeur) ; 

■ destructeur ne lancant pas d'exceptions (indispensable pour la robustesse du 
code) ; 

■ existence d'un operateur d' affectation robuste aux exceptions (afin de garantir, 
qu'en cas d'echec de 1' affectation, l'objet cible est inchange). Notons au passage 



1. Ce n'est pas systematique ; le conteneur vector de la bibliotheque standard est un 
contre-exemple bien connu. 

2. Sauf dans un cas subtil : si la fonction Push() realise une reallocation du tableau 
interne (augmentation de la taille) mais que l'affectation v_[vused_]= t echoue sur 
une exception, l'objet stack reste dans un etat coherent, mais les references vers les 
objets internes initialement obtenues par appel a la fonction Top ( ) ne sont plus vala- 
bles, la zone memoire interne ayant change d' emplacement. Ce defaut pourrait etre 
aisement corrige en deplacant quelques lignes de code et ajoutant un bloc try/catch, 
mais nous verrons, plus loin dans ce chapitre, une deuxieme implementation de stack 
qui resout ce probleme plus elegamment. 
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que c'est la seule fonction a laquelle il faut imposer d'etre robuste aux excep- 
tions pour obtenir une classe stack qui soit elle-meme robuste. 

Dans la suite de ce chapitre, nous allons voir comment il est possible de diminuer 
les contraintes imposees a t, tout en conservant une parfaite robustesse aux excep- 
tions. Nous nous interesserons egalement a l'instruction « delete [ ] x » et a ses dan- 
gers. 



Pb n° 1 2. Ecrire du code robuste aux exceptions 

(5 e partie) Difficulte : 7 



Nous nous attaquons maintenant a la realisation de deux nouvelles versions du conteneur 

Stack. 



Nous disposons deja d'une premiere version de stack tout a fait robuste aux 
exceptions. Dans ce probleme et les suivants, nous allons realiser deux versions diffe- 
rentes de stack, fournissant ainsi trois solutions completes au probleme original de 
Cargill. 

Les deux nouvelles solutions permettront de pallier certaines imperfections de la 
version de stack obtenue pour l'instant, sur laquelle on peut legitimement se poser les 
questions suivantes : 

■ N'existe un moyen plus efficace de gerer les zones de memoire dynamiques et, en 
particulier, de supprimer le bloc try/catch ? 

■ Est-il possible de reduire le nombre des contraintes imposees au type contenu (t) ? 

■ Le modele de classe stack - et, plus generalement, tout conteneur generique - 
doit-il avoir recours a des specifications d' exception dans sa declaration ? 

■ Quelles operations effectuent reellement les operateurs new [ ] et delete [ ] ? 

La reponse a cette derniere question pourra peut-etre vous surprendre ; elle sera en 
tous cas 1' occasion d'insister sur le fait qu'une bonne comprehension des mecanismes 
d' exception passe obligatoirement par une maitrise parfaite des operations executees 
par le code, notamment toutes les conversions implicites, invocations d' operateurs 
redefinis et utilisations d'objets temporaires pouvant se cacher derriere un banal appel 
de fonction, chacune de ces operations pouvant potentiellement generer une excep- 
tion 1 . 

Un premier point sur lequel on peut ameliorer le fonctionnement de stack est la 
gestion des zones de memoire dynamique, qu'il est possible d'encapsuler dans une 
classe utilitaire separee : 



1 . Sauf celles ayant recours explicitement a la specification d'exception throw ( ) dans leur 
declaration, ainsi que quelques fonctions de la bibliotheque standard, dument documen- 
tees. 
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template <class T> class Stacklmpl 
{ 

/*????*/: 

Stacklmpl ( size_t size=0); 
-Stacklmpl ( ) ; 

void Swap (StacklmplS other) throw (); 

T* v_; // Pointeur vers une zone memoire 

// allouee dynamiquement 
size_t vsize_; // Taille totale de la zone memoire 
size_t vused_; // Taille actuellement utilisee 

>; 

private : 

// Prive et non defini. Pas de copie possible 
Stacklmpl ( const StacklmplS ) ; 
StacklmplS operator= ( const StacklmplS ); 

}; 

On retrouve dans stacklmpl toutes les variables membres initialement situees 
dans stack. On note la presence d'une fonction swap ( ) permettant d'echanger la 
valeur de l'objet sur lequel elle est implementee avec celle de l'objet passe en parame- 
tre. 

1. Implementez les trois fonctions membres de stacklmpl, en tenant compte cette 
fois de la contrainte complementaire suivante : le nombre d'objets construits situes 
dans le tableau interne doit etre exactement egal au nombre d'objets dans la pile 
(en particulier, l'espace inutilise ne doit pas contenir d'objets construits). 

2. Quel est le role de stacklmpl ? 

3. Par quoi peut-on remplacer le commentaire / *????*/ ? Argumentez votre reponse. 



-<^>- Solution 



Nous presentons ici une implementation possible pour chacune des trois fonctions 
membres de la stacklmpl. Les mecanismes de gestion des exceptions sont tres simi- 
laires a ceux deja rencontres au debut de ce chapitre ; a ce titre, nous ne les re-expose- 
rons pas en detail. 

En revanche, nous commencerons par introduire quelques fonctions utilitaires 
courantes, qui seront utilisees pour 1' implementation de stacklmpl et stack, dans ce 
probleme et les suivants. 



Constructeur 

Le constructeur est relativement facile a implementer. Nous utilisons l'operateur 
« new sizeof (T) *size » pour implementer un tableau d'octets (car si nous avions 
utilise l'instruction « new t [size] », le tableau aurait ete initialise avec des objets t 
construits, ce qui a ete explicitement proscrit par l'enonce du probleme). 
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Quelques fonctions utilitaires 



Nous presentons ici trois fonctions utilitaires que nous reutiliserons dans la suite du chapitre : 
construct ( ) , qui permet de construire un objet a une adresse memoire donnee en lui affectant 
une valeur donnee, destroy o , qui permet de detruire un objet (nous en verrons deux ver- 
sions) et swap ( ) , directement inspiree de la bibliotheque standard, qui echange deux valeurs. 

// construct () : construit un nouvel objet 

// a une adresse donnee, en 1' initialisant 

/ / avec une valeur donnee 

template <class Tl, class T2> 

void construct ( Tl* p, const T2& value ) 

{ 

new (p) Tl (value) ; 

} 

Utilise avec cette syntaxe, l'operateur « new » construit un nouvel objet ti en le placant a 
l'adresse p (placement new) ; aucune memoire n'est allouee dynamiquement. Un objet 
construit de cette facon doit, sauf cas particulier, etre detruit par un appel explicite au des- 
tructeur, et non pas avec l'operateur delete. 

// destroy () : detruit un objet 
// ou un tableau d'objets 

// 

template <class T> 
void destroy) T* p ) 
{ 

P->~T() ; 

} 

template <class Fwdlter> 

void destroy) Fwdlter first, Fwdlter last ) 
{ 

while ( first != last ) 
{ 

destroy) &*first ); 
++first; 

} 

} 

La premiere de ces deux fonctions est symetrique de la fonction construct o et effectue, 
comme preconise, un appel explicite du destructeur. Quant a la deuxieme, nous aurons 
l'occasion de voir sa grande utilite tres prochainement. 

// swap() : echange deux valeurs 

// 

template <class T> 
void swap) T& a, T& b ) 
{ 

T temp (a); a = b; b = temp; 

} 
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template <class T> 

StackImpl<T> : : Stacklmpl ( size_t size ) 
: v_( static_cast<T*> 
( size == 0 
? 0 

: operator new ( sizeof (T )* size ) ) ), 
vsize_ (size) , 
vused_ (0 ) 

{ 
} 



Destructeur 

Le destructeur est la plus facile des trois fonctions. Nous Fimplementons ici en 
fonction de destroy ( ) , vue plus haut et de l'operateur delete ( ) , dont il faut se rappe- 
ler ce qui a ete vu dans les problemes precedents. 

template <class T> 
StackImpl<T> : : -Stacklmpl ( ) 
{ 

destroy) v_, v_+vused_ ); / / Ne peut pas lancer d' exception 
operator delete ( v_ ) ; 

} 



La fonction Swap() 

Et, pour finir, la fonction swap ( ) qui nous sera d'une extreme utilite dans l'imple- 
mentation de stack ; notamment pour la fonction operator= o , comme nous allons 
le voir bientot. 

template <class T> 

void StackImpl<T> : : Swap ( StacklmplS other) throw () 
{ 

swap ( v_, other. v_ ); 

swap ( vsize_, other. vsize_ ) ; 
swap ( vused_, other. vused_ ) ; 

} 




V/////A 




Figure 1. Deux objets stackimpl<T> a etb 
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Pour mieux visualiser le fonctionnement de swapo, prenons l'exemple de deux 
objets stackimpi<T> a et b, represented sur la figure 1. 

Voici ce que deviennent ces deux objets apres execution de 1' instruction 

a . Swap (b) '. 







vsize\ 


= 15 


vused_ 




b 






vsize_ 


= 20 


vused_ 


= 10 



VZZZZZA 



Figure 2. Les memes objets stackimpl<T>, apres a . Swap (b) 



On peut noter au passage que la fonction swap o ne generera jamais d'exception, 
par construction. C'est d'ailleurs pour cela qu'elle sera la pierre angulaire de la robus- 
tesse aux exceptions de notre nouvelle version de stack. 

La raison d'etre de stackimpi est simple : son role est de masquer a la classe 
externe stack les details d' implementation lies a la gestion des zones de memoire 
dynamique. D'une maniere generale, il est toujours preferable de recourir le plus pos- 
sible a 1' encapsulation et de separer les responsabilites. 



Recommandation 

Efforcez-vous de toujours decouper votre code de maniere a ce que chaque unite d'execu- 
tion (chaque module, chaque classe, chaque fonction) ait une responsabilite unique et bien definie. 



Passons maintenant a la troisieme question : par quoi peut-on remplacer le com- 
mentaire /*????*/ inclus dans la declaration de stackimpi ? La veritable question 
sous-jacente est plutot : comment stackimpi sera-t-elle utilisee par stack ? II y a en 
C++ deux possibilites techniques pour mettre en oeuvre une relation « EST-IMPLE- 
MENTE-EN-FONCTION-DE »: l'utilisation d'une classe de base privee ou 1' utilisa- 
tion d'une variable membre privee. 

Technique n° 1 : classe de base privee. Dans ce cas de figure, le commentaire doit 
etre remplace par protected 1 (les fonctions privees ne pouvant pas etre appelees 
depuis la classe derivee). La classe stack deriverait de la classe stackimpi de 
maniere privee et lui deleguerait toute la gestion de la memoire, assurant pour sa part, 



1. L'emploi de public serait egalement techniquement possible, mais pas conforme a l'uti- 
lisation que Ton souhaite faire de stackimpi ici. 
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outre les diverses fonctionnalites du conteneur, la construction des objets t contenus. 
Le fait de separer clairement l'allocation/desallocation du tableau de la construction/ 
destruction des objets contenus presente de nombreux avantages : en particulier, nous 
sommes certains que l'objet stack ne sera pas construit si l'allocation - effectuee 
dans le constructeur de stackimpi - echoue. 

Technique n° 2 : membre prive. Dans cette deuxieme solution, le commentaire doit 
etre remplace par public. Le conteneur stack serait toujours « IMPLEMENTE-EN- 
FONCTION-DE » de la classe stackimpi, mais en lui etant cette fois lie par une rela- 
tion de type « A-UN ». Nous avons, ici encore, une separation nette des responsabilites : 
la classe stackimpi gerant les ressources memoires tandis que la classe stack gere la 
construction/destruction des objets contenus. Du fait que le constructeur d'une classe est 
appele apres les constructeurs des objets membres, nous sommes egalement assures que 
l'objet stack ne sera pas construit si l'allocation de la zone memoire echoue. 

Ces deux techniques sont tres similaires mais presentent neanmoins quelques dif- 
ferences. Nous allons etudier successivement l'une puis 1' autre, dans les deux proble- 
mes suivants. 



PB N° 13. ECRIRE DU CODE ROBUSTE AUX EXCEPTIONS 

(6 e partie) Difficulte : 9 



Nous etudions dans ce probleme une nouvelle version de stack, utilisant stackimpi comme 
classe de base, qui nous permettra de diminuer le nombre de contraintes imposees au type 
contenu et d'obtenir une implementation tres elegante de I'operateur d'affectation. 



Le but de ce probleme est d'implementer une deuxieme version du modele de 
classe stack, derivant de la classe stackimpi etudiee dans le probleme precedent 
(dans laquelle on remplacera done le commentaire par protected) : 

template <class T> 

class Stack : private StackImpl<T> 
{ 

public : 

Stack (size_t size=0); 
-Stack ( ) ; 

Stack (const Stacks); 

Stacks operator= (const Stacks); 

size_t Count () const; 

void Push (const TS); 

Ts Top(); // Lance une exception si la pile est vide 

void Pop(); // Lance une exception si la pile est vide 

}; 

Proposez une implementation pour chacune des fonctions membres de stack, en 
faisant bien entendu appel aux fonctions adequates de la classe de base stackimpi. 
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Bien entendu, la classe stack doit toujours etre parfaitement robuste aux exceptions. 
Signalons, au passage, qu'il existe une maniere tres elegante d'implementer la fonc- 

tion operator= ( ) . 




Constructeur par defaut 

Voici une proposition d' implementation pour le constructeur par defaut de 
stack (on presente une implementation en-ligne a des fins de concision) : 

template <class T> 

class Stack : private StackImpl<T> 
{ 

public : 

Stack (size_t size=0) 
: StackImpl<T> (size) 

{ 
} 

Ce constructeur fait simplement appel au constructeur de la classe de base stac- 
kimpi, lequel initialise l'etat de l'objet et effectue l'allocation initiale de la zone 
memoire. La seule fonction susceptible de generer une exception est le constructeur 
de stackimpi. II n'y a done pas de risque de se retrouver dans un etat incoherent : si 
une exception se produit, l'objet stack ne sera jamais construit (voir le probleme n° 8 
pour plus de details au sujet des constructeurs lancant des exceptions). 

On peut noter au passage une legere modification de la declaration du constructeur 
par defaut par rapport aux problemes precedents : nous introduisons ici un parametre 
size, avec une valeur par defaut de 0, permettant de specifier la faille initiale du 
tableau et que nous aurons l'occasion d'utiliser lors de 1' implementation de la fonc- 
tion Push. 



Recommandation 

Pour une meilleure robustesse aux exceptions, encapsulez le code gerant les ressources 
externes (zones de memoire dynamique, connexions a des bases de donnees,...) en le separant 
du code utilisant ces ressources. 



Destructeur 

Nous n'avons pas besoin d'implementer de destructeur specifique pour la classe 
stack, ce qui est assez elegant. En effet, le destructeur de stackimpi, appele par 
1' implementation par defaut du destructeur de stack, detruit correctement tous les 
objets contenus et effectue la deallocation du tableau interne. 
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Constructeur de copie 

Voici une proposition d' implementation, utilisant la fonction construct o 
detaillee lors du probleme precedent : 

Stack (const Stacks other) 

: StackImpl<T> (other . vused_) 

{ 

while ( vusecL < other. vusecL ) 
{ 

construct ( v_+vused_, other . v_ [vused_] ); 
++vused_; 

} 

} 

Nous avons ici une implementation efficace et elegante du constructeur de copie 
de stack (dont on peut remarquer, au passage, qu'elle ne fait pas appel au 
constructeur de copie de stackimpi). Si le constructeur de t - appele depuis la fonc- 
tion construct ( ) - lance une exception (c'est la seule source possible ici), le destruc- 
teur de stackimpi est appele, ce qui a pour effet de detruire tous les objets t deja 
constants et de desallouer correctement le tableau memoire interne. Nous voyons ici 
l'un des grands avantages de l'utilisation de stackimpi comme classe de base : nous 
pouvons implementer autant de constructeurs de stack que nous le desirons, sans 
avoir a nous soucier explicitement des destructions et deallocations en cas d'echec de 
la construction. 



Operateur d 'affectation 

Nous presentons ici une version tres elegante et tres robuste de l'operateur d'affec- 
tation de stack : 

Stacks operator= (const Stacks other) 
{ 

Stack temp(other); // Fait tout le travail 

Swap ( temp ); // Ne peut pas lancer d' exception 

return *this; 

} 

Elegant, n'est-ce pas ? Nous avons deja vu ce type de technique lors du probleme 
n° 10, rappelons-en le principe fondateur : 



Recommandation 

Lorsque vous implementez une fonction destinee a realiser une certaine operation, sepa- 
rez les instructions effectuant I'operation elle-meme (susceptibles de generer une exception), du 
code realisant la validation de cette operation, constitue d'instructions unitaires (ne risquant pas 
de generer des exceptions). 
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Nous construisons un objet stack temporaire (temp), initialise a partir de l'objet 
source (other) puis nous appelons swap (membre de la classe de base) pour echanger 
l'etat de notre objet temporaire avec celui de l'objet passe en parametre; lorsque la 
fonction se termine, le destructeur de temp est automatiquement appele, ce qui a pour 
effectuer de desallouer correctement toutes les ressources liees a l'ancien etat de notre 
objet Stack. 

Notons qu'implemente de cette maniere, l'operateur d' affectation gere correcte- 
ment, de maniere native, le cas de 1' auto-affectation ( « stack s; s=s; »). Voir le 
probleme n° 38 pour plus d' informations sur 1' auto- affectation, et notamment sur 
l'emploi du test « if (this ! = sother ) » dans un operateur d' affectation). 

Les sources d' exceptions potentielles sont 1' allocation ou la construction des 
objets t. Comme elles ne peuvent se produire que lors de la construction de l'objet 
temp, nous sommes assures qu'en cas d'echec, l'impact sur notre objet stack sera 
nul. II n'y a pas non plus de risque de fuite memoire liee a l'objet temp, car le 
constructeur de copie de stack est parfaitement robuste de ce point de vue. Une fois 
que nous sommes certains que Foperation a ete effectuee correctement, nous la vali- 
dons en mettant a jour l'etat de notre objet stack grace a la fonction swap ( ) , laquelle 
ne peut pas lancer d' exceptions (elle est declaree avec une specification d' exceptions 
throw et n'effectue, de toute facon, que des copies de valeurs de types predefinis). 

Cette implementation est largement plus elegante que celle proposee lors du pro- 
bleme n° 9; elle est egalement plus simple, ce qui permet de s' assurer d'autant plus 
facilement de son bon comportement en presence d' exceptions. 

II est d'ailleurs possible de faire encore plus compact, en utilisant un passage par 
valeur au lieu d'une variable temporaire : 

Stacks operator= (Stack temp) 

{ 

Swap ( temp ) ; 
return *this; 

} 



La fonction Stack<T>::Count 

C'est, de loin, la plus facile. 

size_t Count () const 

{ 

return vused_; 

} 



La fonction Stack<T>::Pu$h 

Cette fonction est un peu plus complexe. Prenez le temps de l'etudier un moment 
avant de lire le commentaire qui suit. 
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void Push ( const T& t ) 
{ 

if ( vused_ == vsize_ ) // grow if necessary 
{ 

Stack temp ( vsize_*2+l ); 
while ( temp. Count () < vused_ ) 
{ 

temp. Push ( v_ [temp . Count () ] ) ; 

} 

temp . Push ( t ) ; 
Swap ( temp ) ; 

} 

else 
{ 

construct ( v_+vused_, t ) ; 
++vused_; 

} 

} 

Nous distinguons deux cas dans cette implementation, suivant qu'il faut augmen- 
ter ou non la taille du tableau interne. 

Commencons par le cas le plus simple : s'il reste de la place allouee mais non 
occupee dans le tableau interne, nous appelons la fonction construct ( ) pour tenter de 
placer l'objet a ajouter dans ce tableau et, si l'operation reussit, nous mettons a jour la 
taille utilisee (vusedj. 

L' autre cas est un peu plus complexe : s'il est necessaire d'agrandir le tableau, 
nous construisons un objet stack temporaire (temp) auquel nous ajoutons tous les ele- 
ments actuellement contenus dans notre objet stack, ainsi que l'objet t passe en para- 
metre de la fonction Pusho; pour finir, nous utilisons la fonction swapo pour 
echanger l'etat de notre objet avec celui de l'objet temporaire. 

Est-ce robuste aux exceptions ? La reponse est oui : 

■ Si la construction de temp echoue, l'etat de notre objet stack est inchange et il n'y 
pas de fuite memoire, ce qui est correct. 

■ Si l'une des operations de chargement de l'objet temp echoue et lance une excep- 
tion (soit lors de l'ajout a temp d'un objet existant, soit lors de la construction ou 
de l'ajout a temp du nouvel objet, copie de t), les ressources sont correctement 
liberees lors de la destruction de temp, qui se produit automatiquement lorsque la 
fonction Push se termine) 

■ Dans aucun cas, nous ne modifions pas l'etat de notre objet stack original tant que 
l'operation d'ajout du nouvel element n'a pas ete correctement effectuee. 

Nous avons done ici un solide mecanisme de « validation ou annulation », la fonc- 
tion swap ( ) n'etant executee que si les operations de reallocation eventuelle et d'ajout 
du nouvel element se sont correctement terminees. En particulier, nous avons elimine 
le risque de corruption des references vers les objets contenus qui pouvait survenir 
suite a un appel de Push ( ) effectuant une reallocation suivie d'un echec de l'ajout du 
nouvel element, ainsi que nous 1' avons vu lors du probleme n° 1 1. 
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La fonction Stack<T>::Top 

La fonction Top ( ) reste inchangee. 

T& Top() 

{ 

if ( vused_ == 0 ) 
{ 

throw "Pile vide"; 

} 

return v_ [vused_-l ] ; 

} 



La fonction Stack<T>::Pop 

La fonction Pop ( ) egalement, a part l'appel supplementaire a destroy { ) . 

void Pop ( ) 
{ 

if ( vused_ == 0 ) 
{ 

throw "Pile vide"; 

} 

else 
{ 

— vused_; 

destroy ( v_+vused_ ) ; 

} 

} 

En resume, l'utilisation de stackimpi comme classe de base nous a permis de sim- 
plifier 1' implementation des fonctions membres de stack. Lun des plus grands avan- 
tages de la gestion separee des ressources memoires effectuee par stackimpi se 
manifeste dans 1' implementation des constructeurs et du destructeur de stack : d'une 
part, nous pouvons implementer autant de constructeurs de stack que nous le desi- 
rons, sans avoir a nous soucier explicitement des destructions et deallocations en cas 
d'echec de la construction ; d' autre part, il n'est pas necessaire d' implementer un des- 
tructeur pour stack, le destructeur par defaut convient. 

Pour finir, il est interessant de noter que nous avons elimine le bloc try /catch 
contenu dans la premiere version, prouvant ainsi qu'il est tout a fait possible d' imple- 
menter une classe parfaitement robuste aux exceptions sans utiliser un seul bloc try/ 
catch. 
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PB N° 14. ECRIRE DU CODE ROBUSTE 

AUX EXCEPTIONS (7 e PARTIE) DlFFICULTE I 5 



Deuxieme variante de stack, utilisant cette fois stackimpi en tant qu'objet membre. 

Dans ce probleme, on implementera une troisieme version du modele de classe 
stack utilisant un objet membre de type stackimpi (decrite lors du probleme n° 12 ; 
on remplacera le commentaire de la declaration par public). 

template <class T> 

class Stack 

{ 

public : 

Stack (size_t size=0); 
-Stack () ; 

Stack (const Stacks); 

Stacks operator= (const Stacks); 

size_t Count () const; 

void Push (const TS); 

Ts Top(); // Lance une exception si la pile est vide 

void Pop(); // Lance une exception si la pile est vide 
private : 

StackImpl<T> impl_; // Objet prive 

}; 

Proposez une implementation pour chacune des fonctions membres de stack. 
N'oubliez pas la robustesse aux exceptions. 



Solution 



L' implementation etant extremement similaire a la version precedente, nous pre- 
sentons directement le code (les fonctions sont en-lignes, a des fins de concision) : 

template <class T> 

class Stack 

{ 

public : 

Stack (size_t size=0) 
: impl_(size) 

{ 
} 

Stack (const Stacks other) 

: impl_ ( other . impl_. vused_) 

{ 

while ( impl_.vused_ < other . impl_. vused_ ) 
{ 

construct ( impl_ . v_+impl_ . vused_, 

other . imp 1_. v_ [ impl_. vused_] ); 
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++impl_. vused_; 

} 

} 

Stacks operator= (const Stacks other) 
{ 

Stack temp (other); 

impl_. Swap (temp . impl_) ; // this can't throw 
return *this; 

} 

size_t Count () const 

{ 

return impl_ . vused_; 

} 

void Push ( const TS t ) 
{ 

if ( impl_.vused_ == impl_.vsize_ ) 

{ 

Stack temp ( impl_. vsize_*2+l ); 
while ( temp. Count () < impl_.vused_ ) 
{ 

temp. Push ( imp 1_. v_ [ temp . Count () ] ); 

} 

temp . Push ( t ) ; 
impl_.Swap( temp.impl_ ) ; 

} 

else 

{ 

construct ( impl_. v_+impl_ . vused_, t ); 
++impl_. vused_; 

} 

} 

TS Top() 

{ 

if ( impl_.vused_ == 0 ) 

{ 

throw "Pile vide"; 

} 

return impl_ . v_ [ impl_. vused_-l ] ; 

} 

void Pop ( ) 
{ 

if ( impl_.vused_ == 0 ) 

{ 

throw "Pile vide"; 

} 

else 

{ 

— impl_. vused_; 

destroy ( impl_. v_+impl_. vused_ ); 

} 

} 

private : 

StackImpl<T> impl_; // Objet prive 
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Nous avons ainsi, dans ce probleme et le precedent, obtenu deux nouvelles imple- 
mentations possibles de stack. Chacune a ses avantages et ses inconvenients, ainsi 
que nous allons le voir dans le probleme suivant. 



PB N° 15. ECRIRE DU CODE ROBUSTE 

AUX EXCEPTIONS (8 e partie) DlFFICULTE I 9 



Prenons un moment pour comparer les trois implementations differentes de stack obtenues 
jusqu'ici. 

1 . Vaut-il mieux utiliser stackimpi comme classe de base ou comme objet membre ? 

2. Dans quelle mesure les deux dernieres versions de stack sont-elles reutilisables ? 
Quelles contraintes imposent-elles a t, le type contenu ? Note : plus les contraintes 
sur t sont faibles, plus le conteneur est reutilisable de maniere generique. 

3. La classe stack doit-elle avoir recours a des specifications d'exceptions dans les 
declarations de ses fonctions membres ? 




Repondons aux questions dans l'ordre : 

1 . Vaut-il mieux utiliser stackimpi comme classe de base ou comme objet membre ? 

Ces deux methodes sont relativement similaires et permettent toutes les deux 
d'obtenir un partage net des responsabilites entre allocation/desallocation et 
construction/destruction. 

En regie generale, lorsqu'on a besoin de mettre en oeuvre une relation du type 
« EST-IMPLEMENTE-EN-FONCTION-DE », il est preferable d' utiliser la composi- 
tion (utilisation d'un objet membre) plutot que la derivation (utilisation d'une classe 
de base), lorsque cela est possible. En effet, la composition presente l'avantage de 
masquer completement la classe stackimpi. Ainsi, le code client ne voit que l'inter- 
face publique de stack et n'est par consequent pas dependant de stackimpi. II est 
neanmoins parfois obligatoire de faire deriver la classe utilisatrice de la classe utili- 
taire dans certains cas : 

■ Besoin d' acceder a une fonction protegee de la classe utilitaire. 

■ Besoin de redefinir une fonction virtuelle de la classe utilitaire. 

■ Besoin de construire l'objet utilitaire avant d'autres objets de base de la classe uti- 
lisatrice. 1 



1. On pourrait egalement rajouter une quatrieme raison, un peu moins dependable, de 
confort d'ecriture (le fait d'utiliser une classe de base permettant de s'affranchir de 
nombreux « impl_. ») 
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2. Dans quelle mesure les deux dernieres versions de stack sont-elles reutilisables ? 
Quelles contraintes imposent-elles a t, le type contenu ? 

Lorsque vous implementez un modele de classe - et, qui plus est, lorsque ce 
modele est destine a servir de conteneur - posez-vous toujours la question de la reuti- 
lisabilite de votre code. Plus votre modele imposera de contraintes au niveau du code 
client, moins il sera reutilisable. Dans le cas de notre exemple stack, il s'agit de 
savoir qu'elles sont les contraintes imposees a t, le type contenu (et, en particulier, si 
le nombre de ces contraintes a ete reduit par rapport a la premiere version de stack). 

Nous avons deja vu que la difference principale entre les deux nouvelles versions 
de stack et la version precedente se situe au niveau de la gestion de la memoire 
(separation des responsabilites d' allocation / deallocation et construction / destruc- 
tion). Cette evolution permet une meilleure robustesse aux exceptions, mais ne change 
pas grand chose aux contraintes imposees a t. 

Une autre difference est que les nouvelles versions de stack construisent et detrui- 
sent les objets contenus au fur et a mesure de leur ajout/suppression de la pile, a 
l'inverse de la premiere version qui remplissait son tableau interne avec des objets 
construits par le constructeur par defaut. Ceci augmente la performance de la classe 
stack, mais surtout, permet de diminuer les contraintes imposees au type contenu. 

Rappelons quelles etaient ces contraintes avec la premiere version de stack : 

■ Existence d'un constructeur par defaut (necessaire pour la bonne compilation de 
l'instruction « new t [ . . . ] ») 

■ Existence d'un constructeur de copie (dans le cas ou Pop retourne un objet par 
valeur) 

■ Destructeur ne lancant pas d'exceptions (indispensable pour la robustesse du code) 

■ Existence d'un operateur d' affectation robuste aux exceptions (afin de garantir, 
qu'en cas d'echec de 1' affectation, l'objet cible est inchange). 

Dans les nouvelles versions de stack, seul le constructeur de copie de t est uti- 
lise : il n'est done pas necessaire d'imposer a t d' avoir un constructeur par defaut et 
un operateur d' affectation. Les contraintes imposees a t par les nouvelles versions ne 
sont done qu' au nombre de deux : 

■ Existence d'un constructeur de copie 

■ Destructeur ne lancant pas d'exceptions 

Ceci ameliore la reutilisabilite de notre conteneur stack, par rapport a la version 
originale. II existe en effet de nombreuses classes n' ay ant pas de constructeur par 
defaut ou pas d' operateur d' affectation (comme, par exemple, les classes contenant 
des membres de type reference, pour lesquelles on souhaite parfois interdire 1' affecta- 
tion). Ce type de classe peut maintenant etre stocke dans notre nouveau conteneur 
Stack. 



Recommandation 

Pensez des la conception a la reutilisabilite de votre code. 
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3. La classe stack doit-elle avoir recours a des specifications d'exceptions dans les 
declarations de ses fonctions membres ? 

La reponse est non. La raison principale en est que l'auteur de stack n'a a priori 
aucune idee du comportement que va avoir le type contenu t ; il ignore en particulier si les 
fonctions membres de t vont generer des exceptions et, si c'est le cas, quels types d'excep- 
tions. Introduire des specifications d' exception irait done totalement a Fencontre de la reu- 
tilisabilite de stack, imposant des contraintes supplementaires sur le type contenu. 

D'un autre cote, il y a certaines fonctions membres pour lesquelles on est certain 
qu'elles ne lanceront pas d' exception (par exemple, count ()). On pourrait etre tente 
de specifier « throw o » au niveau de la declaration de ces fonctions. Ce n'est pas 
souhaitable pour deux raisons : 

■ Appliquer une specification throw ( ) a une fonction membre impose des contraintes 
supplementaires a votre code : vous vous interdisez, par exemple, de substituer a 
F implementation de cette fonction une nouvelle version susceptible de generer des 
exceptions, sous peine de perturber fortement les clients, s'attendant a ce qu'aucune 
exception ne soit generee. Autre exemple, appliquer « throw ( ) » a une fonction vir- 
tuelle impose que les fonctions redefinies ne generent pas d' exception. II ne faut certes 
pas en conclure qu'il ne faut jamais utiliser throw() ; il faut neanmoins en faire un 
usage prudent. 

■ Les specifications d'exceptions peuvent etre couteuses en terme de performances 
(bien que, sur ce point, les compilateurs s'ameliorent de jour en jour). II est done 
preferable de les eviter pour les fonctions et classes utilisees frequemment, comme 
par exemple, les conteneurs generiques. 



PB N° 16. ECRIRE DU CODE ROBUSTE AUX EXCEPTIONS 

(9 e partie) Difficulte : 8 



Connaissez-vous bien les operations effectuees I'instruction delete net leur impact sur la 
robustesse aux exceptions ? 

Considerez I'instruction « delete [ ] p », p pointant vers un tableau en memoire 
globale ayant ete correctement alloue et initialise par une instruction « new [ ] ». 

1 . Detaillez precisement les operations effectuees par I'instruction « delete [ ] p ». 

2. Ces operations presentent-elles des dangers ? Argumentez votre reponse. 



Solution 



Ce probleme va etre l'occasion d'aborder les dangers de I'instruction « delete 
», dont l'apparente innocence est trompeuse. 
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Les dangers des destructeurs lancant des exceptions 

Rappelons-nous la fonction utilitaire destroy ( ) vue lors du probleme n° 12 : 

template <class Fwdlter> 

void destroy! Fwdlter first, Fwdlter last ) 
{ 

while) first != last ) 

{ 

destroy ( &*first ); 
++f irst; 

} 

} 

Lors des problemes precedents, cette fonction se comportait correctement car nous 
avions fait l'hypothese que le destructeur de t ne lancait pas d'exceptions. Si cette 
condition n'est pas respectee et qu'une exception est generee, disons, lors du premier 
destroy o d'une serie de cinq, la fonction s'arretera prematurement, laissant en 
memoire quatre objets impossibles a detruire, ce qui n'est evidemment pas une bonne 
solution. 

On pourrait certes arguer qu'il doit etre possible d'ecrire une fonction destroy o 
capable de gerer correctement le cas d'une exception lancee depuis le destructeur de t, 
avec une implementation du type : 

template <class Fwdlter> 

void destroy ( Fwdlter first, Fwdlter last ) 
{ 

while ( first != last ) 

{ 

try 

{ 

destroy ( &*first ); 

} 

catch (...) 

{ 

/* que faire ici ? */ 

} 

++f irst; 

} 

} 

Bien evidemment, toute la question est ici de decider quel traitement on va effec- 
tuer dans le bloc catch. II y a trois solutions possibles : relancer l'exception ; la 
convertir puis relancer une exception differente ; ne pas relancer d' exception et 
continuer la boucle. 

1 . Si le bloc « catch » relance l'exception, la fonction destroy ( ) sera certes partiel- 
lement robuste aux exceptions du fait qu'elle retransmettra correctement les excep- 
tions a 1' appelant, mais en revanche tout a fait insatisfaisante du fait qu'elle laissera en 
memoire des objets qui ne pourront jamais etre detruits. II faut done exclure cette pre- 
miere solution. 
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2. Si le bloc « catch » convertit 1' exception et en relance une differente, non seule- 
ment la fonction destroy o provoquera toujours des fuites memoires mais, de plus, 
elle ne retransmettra meme pas correctement les exceptions a 1' appelant. Cette solu- 
tion est done encore pire que la premiere. 

3. Si le bloc « catch » absorbe l'exception et continue la boucle, le probleme inverse 
sera produira : la fonction destroy o ne risquera pas de provoquer de fuites 
memoire 1 , mais elle ne permettra pas a l'appelant de recevoir correctement les excep- 
tions generees (meme si un traitement correct et/ou un enregistrement de l'erreur est 
effectue dans le bloc « catch », ceci ne doit pas dispenser la fonction de retransmettre 
les exceptions a l'appelant). 

D'aucuns suggerent d'utiliser le bloc « catch » pour « enregistrer » temporaire- 
ment l'exception, ce qui permet a la boucle de se terminer normalement, puis de relan- 
cer l'exception en question a la fin de Fexecution de la fonction. Ce n'est pas une 
bonne solution car, si plusieurs exceptions se produisent au cours de la boucle, il n'est 
possible d'en relancer qu'une seule a la fin, meme si elles ont ete toutes enregistrees. 
Toutes les autres alternatives diverses qu'on pourrait imaginer s'averent toutes, 
croyez-moi, deficientes d'un point de vue ou d'un autre. La conclusion est simple : il 
n'est pas possible d'ecrire du code robuste en presence de destructeurs susceptibles de 
lancer des exceptions. 

Ceci nous conduit naturellement a un sujet connexe : le comportement des opera- 
teurs new [ ] et delete [ ] en presence d'exceptions. 

Considerons par exemple le code suivant : 

T* p = new T [10] ; 
delete [ ] p ; 

Ceci est sans aucun doute du C++ standard, comme vous avez surement eu l'occa- 
sion d'en ecrire tous les jours. Neanmoins, vous etes-vous deja pose la question de 
savoir ce qui se passerait si l'un des destructeurs de t lancait une exception ? Quand 
bien meme vous vous la seriez posee, il est probable que vous n'eussiez pas trouve de 
reponse satisfaisante ; pour la bonne raison qu'il n'y en a pas : en effet, la norme C++ 
ne precise pas le comportement que doit adopter 1' instruction delete [ ] dans le cas ou 
le destructeur d'un des objets detruits lance une exception. Aussi surprenant que celui 
puisse paraitre aux yeux de certains, un echec de « delete [ ] p » conduira done a un 
etat indetermine. 

Supposons, par exemple, que toutes les constructions des objets se passent correc- 
tement mais que la destruction du cinquieme objet echoue. L'operateur delete [] se 
retrouve alors face au meme dilemme vu precedemment : soit il continue la deallo- 
cation des quatre objets restants, evitant ainsi les fuites memoires, mais interdisant la 
retransmission correcte des exceptions a l'appelant (en particulier, s'il se produisait 



1 . A moins que le destructeur de T ne libere pas correctement toutes les ressources memoi- 
res dynamique le concernant au moment ou il lance une exception ; mais, dans ce cas, 
e'est la robustesse de T aux exceptions qui est en cause, pas celle de destroy ( ) . 
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plusieurs exceptions, seule une pourrait etre retransmise) ; soit il retransmet immedia- 
tement 1' exception survenue, laissant en memoire des objets impossibles a detruire. 

Autre cas de figure : supposons que la construction d'un objet, le cinquieme par 
exemple, echoue. Les destructeurs des objets deja construits sont alors appeles, dans 
l'ordre inverse de la construction (le quatrieme, puis le troisieme, etc.). Mais que se 
passe t-il si l'un des destructeurs appeles lance a son tour une exception ? Faut-il 
continuer a detruire les autres objets, operations risquant, a leur tour, de lancer 
d'autres exceptions ? Faut-il retransmettre immediatement 1' exception en laissant des 
objets non detruits en memoire ? Une nouvelle fois, la situation est inextricable. 

Si un destructeur est susceptible de lancer des exceptions, il n'est pas possible 
d' avoir recours aux operateurs new [ ] et delete [ ] , sous peine d'obtenir du code non 
robuste. La conclusion est simple : n 'implementez jamais un destructeur susceptible 
de generer ou de retransmettre une exception 1 . Tous les destructeurs doivent etre 
implemented comme s'ils etaient declares avec Fattribut throw ( ) ; c'est-a-dire qu'ils 
ne doivent, en aucun cas, propager la moindre exception. 



Recommandation 

Ne laissez jamais une exception s'echapper d'un destructeur ou d'un operateur delete ( ) 
ou delete [ ] ( ) redefini, sous peine de compromettre la robustesse de votre code. Implemen- 
tez toutes les fonctions de ce type comme si elles etaient dotees de I'attribut throw ( ) . 



Ceci peut paraitre decevant, quand on pense que les exceptions ont ete originale- 
ment introduites en C++ pour permettre aux constructeurs et aux destructeurs de 
signaler des erreurs - etant donne qu'ils ne disposent pas de valeur de retour. En rea- 
lite, l'utilite pratique est principalement restreinte aux constructeurs - les destructeurs 
n'ayant, en general, que tres peu de risques de mal s'executer. II est done peu domma- 
geable d'interdire a un destructeur de transmettre des exceptions. Quant au cas de 
constructeurs lancant des exceptions, il est heureusement parfaitement gere en C++, 
meme dans le cas de la construction de tableaux dynamiques d'objets avec new [ ] . 



Du bon usage des exceptions 

Ce probleme et les precedents ont mis en avant un certain nombre de risques pou- 
vant se presenter en cas de mauvaise utilisation des exceptions. N'en concluez pas que 
les exceptions sont dangereuses ! Utilisees correctement, elles restent un outil extre- 
mement performant de remontee d' erreurs. II suffit de respecter un certain nombre de 



1. Lors de 1' adoption de la version finale de la norme C++ en novembre 1997 a Morristown 
(New Jersey), le comite de normalisation C++ a notamment edicte qu' « aucun des des- 
tructeurs defini dans la bibliotheque standard C++ ne doit lancer d' exception » et que « les 
conteneurs standards ne doivent pas pouvoir etre instancies avec une classe dont le des- 
tructeur est susceptible de lancer des exceptions ». II existe egalement un certain nombre 
de proprietes supplementaires que nous allons voir dans le probleme suivant. 
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regies simples : encapsuler le code gerant les ressources externes (zones dynamiques 
de memoire, connexions a des bases de donnees), effectuer les operations sur des 
objets temporaires avant de les « valider » en mettant a jour l'etat de l'objet principal, 
ne jamais laisser une exception s'echapper d'un destructeur. 



Recommandation 

Pour une bonne robustesse de votre code aux exceptions, respectez toujours les trois 
regies suivantes : 

(1) Ne laissez jamais une exception s'echapper d'un destructeur ou d'un operateur delete o 
ou delete [] o redefini. Implementez toutes les fonctions de ce type comme si elles etaient 
dotees de I'attribut throw ( ) . 

(2) Encapsulez le code gerant les ressources externes (zones de memoire dynamique, 
connexions a des bases de donnees,...) en le separant du code utilisant ces ressources. 

(3) Lorsque vous implementez une fonction destinee a realiser une certaine operation, separez 
les instructions effectuant I'operation elle-meme (susceptibles de generer une exception), du 
code realisant la validation de cette operation, constitue d'instructions unitaires (ne risquant pas 
de generer des exceptions). 



PB N° 1 7. ECRIRE DU CODE ROBUSTE 

AUX EXCEPTIONS (10 e PARTIE) DlFFICULTE I 9 



Pour conclure cette serie de problemes, nous nous interessons a la robustesse aux exceptions de 




Un travail particulierement important a ete effectue sur la bibliotheque standard 
C++ et de sa robustesse aux exceptions. Les principaux artisans en sont Dave Abra- 
hams, Greg Colvin et Matt Austern, qui ont travaille durement - qu'ils en soient 
remercies ici - pour produire une specification complete sur le sujet quelques jours 
seulement avant l'adoption finale de la norme ISO WG21/ANSI J16 en novembre 
1997 a Morristown (New Jersey). 

La question a laquelle il vous est propose de repondre est la suivante : dans quelle 
mesure la bibliotheque standard C++ est-elle robuste aux exceptions ? Argumentez 
votre reponse. 




Pour repondre succinctement a la question : les conteneurs de la bibliotheque C++ 
standard sont parfaitement robustes aux exceptions - nous en verrons les justifications 
ci-dessous ; le reste de la bibliotheque (en particulier, les iostreams et les facets) ne 
garantissent qu'une robustesse minimale. 
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Robustesse aux exceptions des conteneurs 
standards 

Tous les conteneurs de la bibliotheque standard sont implemented de maniere a 
garantir qu'ils se comportent correctement en presence d'exceptions et transmettent 
toutes les exceptions a 1' appelant : 

■ Tous les iterateurs obtenus a partir d'un conteneur standard sont robustes aux 
exceptions et peuvent etre copies sans risque de generation d' exception. 

■ Tous les conteneurs standards satisfont aux garanties de base de la robustesse aux 
exceptions : ils peuvent etre detruits sans generer d'exceptions et restent toujours 
dans un etat coherent, meme en presence d'exceptions. 

■ Pour rendre possible le point precedent, la bibliotheque standard requiert d'un cer- 
tain nombre de fonctions qu'elles ne generent pas d'exceptions, en aucune 
circonstance : la fonction swap o , dont l'importance pratique a pu etre demontree 
lors des problemes precedents; la fonction aiiocator<T>: : delete () , vue au 
moment de la discussion relative a l'operateur delete ( ) au debut de ce chapitre ; 
ainsi que les destructeurs des types contenus (voir a ce sujet le paragraphe « Les 
dangers des destructeurs lancant des exceptions »). 

■ Toutes les fonctions de la bibliotheque standard (a deux exceptions pres) garantis- 
sent que toutes les zones de memoire dynamiques seront correctement desallouees 
et que les objets resteront toujours dans un etat coherent en cas d'exception. Ces 
fonctions sont toutes implementees suivant la logique « valider ou annuler » : 
toute operation doit etre entierement executee ou, dans le cas contraire, laisser 
inchange l'etat des objets manipules. 

■ Les deux exceptions a cette derniere regie sont les suivantes : d'une part, l'inser- 
tion simultanee de plusieurs elements n'est pas robuste aux exceptions, et ce quel 
que soit le type de conteneur ; d' autre part, les operations d'insertion et de sup- 
pression pour les conteneurs vector<T> et deque<T> ne le sont que si le 
constructeur de copie et l'operateur d' affectation du type contenu ne lancent pas 
d'exception, et ceci qu'il s'agisse d'insertion simple ou multiple. En particulier, 
l'insertion ou la suppression d'elements dans un vector<string> ou un vec- 
tor<vector<int>> peut ne pas se comporter correctement en presence d'excep- 
tions. 

Ces limitations sont le resultat d'un compromis entre performance et securite : 
imposer dans la norme C++ une robustesse parfaite aux exceptions sur les dernieres 
operations citees aurait ete necessairement penalisant en terme de performances ; le 
comite de normalisation a prefere l'eviter. Par consequent, si une exception se produit 
alors que vous effectuez une operation de ce type, les objets manipules risquent de se 
retrouver dans un etat incoherent. Seule solution lorsque vous souhaitez realiser une 
insertion multiple ou une insertion/suppression dans vector<T> ou deque<T> alors 
que le constructeur de copie et/ou l'operateur d' affectation de t sont susceptibles de 
generer des exceptions : effectuer les operations sur une copie du conteneur, puis, une 
fois qu'on est certain que tout s'est deroule correctement, echanger la copie et 1' origi- 
nal avec la fonction swap ( ) , dont on sait qu'elle ne risque pas de generer d'exception. 
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PB N° 18. COMPLEXITE DU CODE (1 re PARTIE) DlFFICULTE I 9 



Ce probleme aborde une question interessante, dont la reponse vous paraftra peut-etre surpre- 
nante : combien y a-t-il de chemins d'execution possibles dans une banale fonction de 




Combien la fonction ci-dessous comporte-t-elle de chemins d'execution possi- 
bles ? 

String Evaluer SalaireEtRenvoyerNom ( Employe e ) 

{ 

if( e. Fonction () == "PDG" I I e.SalaireO > 100000 ) 
{ 

cout<<e . Prenom ( ) <<" " <<e . Norn ()<<" est trop paye"<<endl; 

} 

return e. Prenom () + " " + e.Nom(); 

} 

On fera les hypotheses suivantes : 

■ Les fonctions evaluent toujours les parametres dans le meme ordre. 

■ Les destructions s'effectuent toutes correctement (aucune exception ne peut etre 
generee par un destructeur 1 ). 

■ Les appels de fonctions sont atomiques (une fonction implementant une operation 
la realise soit completement, soit pas du tout). 

■ On nomme « chemin d'execution » une sequence de fonctions executee dans un 
ordre donne et d'une maniere donnee. 



Combien la fonction EvaiuerSaiaireEtRenvoyerNom comporte-t-elle de chemins 
d'execution possibles ? 

La reponse est : 23. 

Vous avez trouve... Votre note 

3 Moyen 
4-14 Bon 
15-23 Excellent 

Ces 23 chemins d'execution se divisent en : 

■ 3 chemins normaux 

■ 20 chemins « exceptionnels », c'est-a-dire survenant en presence d' exceptions. 

1. Ce qui, entre nous, est une bonne chose. Voir, a ce sujet, le paragraphe : « les dangers 
des destructeurs lancant des exceptions » dans le probleme n° 16. 
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Chemins d execution normaux 

Si vous avez trouve le bon nombre de chemins d'executions normaux, c'est que 
vous maitrisez la technique employee par le C++ pour optimiser revaluation des 
expressions conditionnelles : 

if( e.Fonction() == "PDG" | e.SalaireO > 100000 ) 

1. Si la premiere partie de l'expression est verifiee, il n'est pas necessaire d'evaluer 
la seconde partie (e . saiaire ( ) n'est pas appelee et on passe directement a l'inte- 
rieur du bloc if). Remarque : cette optimisation n'aurait pas lieu si l'un des deux 
operateurs | | ou > etait redefini, cas que Ton exclut ici. 

2. Si la premiere partie de l'expression n'est pas verifiee mais que la seconde Test, 
les deux parties de l'expression sont evaluees et on execute l'interieur du bloc if. 

3. Si aucune des deux parties de l'expression n'est verifiee, on evalue les deux parties 
de l'expression mais on ne rentre pas le bloc if. 



Chemins d execution « exceptionnels » 

String EvaluerSalaireEtRenvoyerNom ( Employe e ) 
A 4(bis) A A 4 A 

4. L' argument e etant passe par valeur, le constructeur de copie Employe est appele. 
Cette operation est susceptible de generer une exception. 

4bis. La fonction retournant une valeur, il est possible que le constructeur de copie de 
string, invoque pour copier le contenu de l'objet temporaire renvoye vers le code 
appelant, echoue et genere une exception. On ne comptera pas ce cas comme un 
chemin d'execution supplementaire, vu qu'il peut etre considere comme externe a 
la fonction. 

if( e. Fonction () == "PDG" || e.SalaireO > 100000 ) 

AgA A *y A AgA A^^A A g A A 10 A A Q A 

5. L'appel a Fonction o peut generer une exception, provoquee soit par son imple- 
mentation interne, soit par l'echec de l'operation de copie de l'objet temporaire 
retourne. 

6. La chaine "pdg" est susceptible d'etre converti en un objet temporaire (du meme 
type que celui retourne par Fonction) afin de pouvoir etre transmis en parametre 
de Foperateur == adequat. Cette operation de construction peut echouer. 

7. Si operator==o est une fonction redefinie, elle est susceptible de generer une 
exception. 

8. L'appel asaiaireo peut generer une exception, de maniere tout a fait similaire a 
ce qui a ete vu au (5). 

9. La valeur iooooo peut faire l'objet d'une conversion, laquelle peut generer une 
exception, de maniere similaire a ce qui a ete vu au (6). 

10. Si elle est redefinie, la fonction operator>o peut generer une exception, de 
maniere similaire a ce qui a ete vu au (7). 
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1 1 . Meme remarque pour la fonction operator | | ( ) . 

cout«e.Prenom()«" "«e .Nom() «"est trop paye"«endl; 

A 12 A A 17 A A 13 A A 14 A A^A A^A AJgA 

12-16. Comme le specifie la norme C++, chacun des cinq appels a operator<<() 
peut etre a l'origine d'une exception. 

17-18. De maniere similaire a (5), les fonctions Prenomo et Nom() peuvent generer 
une exception ou renvoyer un objet temporaire dont la copie peut provoquer une 
exception. 

return e.Prenom() + " " + e.Nom(); 

a 19 a *22* A 21 A A 23 A A 20 A 

19-20. Meme remarque que 17-18. 
21. Meme remarque que 6. 

22-23. Meme remarque que pour 7, appliquee a l'operateur +. 



Recommandation 

Sachez ou et quand des exceptions sont susceptibles d'etre generees. 



Nous avons pu voir dans ce probleme dans quelle mesure il est parfois complexe 
de maitriser parfaitement tous les chemins d'execution possibles. Nous allons voir 
dans le probleme suivant quel impact peut avoir cette complexite invisible sur la fiabi- 
lite et la facilite de test d'un code. 



Pb n° 19. Complexite du code (2 e partie) Difficulty : 7 



Dans ce probleme, il s'agit de modifier le code du probleme precedent de maniere a le rendre 
r,bus,eau> excepts. 

La fonction ci-dessous, etudiee lors du probleme precedent, est-elle robuste aux 
exceptions ? Autrement dit, se comporte-t-elle correctement en presence d'excep- 
tions et transmet-elle toutes les exceptions au code appelant ? 

String EvaluerSalaireEtRenvoyerNom ( Employe e ) 
{ 

if( e. Fonction () == "PDG" I I e.SalaireO > 100000 ) 
{ 

cout <<e . Prenom ( ) << " " <<e . Nom ( ) << " est trop paye"<<endl; 

} 

return e. Prenom () + " " + e.Nom(); 

} 



© copyright Editions Eyrolles 



Pb n° 19. Complexite du code (2 e partie) 



67 



Argumentez-votre reponse. Si la fonction n'est pas robuste aux exceptions, peut- 
on au moins assurer qu'en cas d'exception, il ne se produira pas de fuite memoire et/ 
ou que l'etat du programme sera inchange ? Peut-on, a l'inverse, assurer que cette 
fonction ne generera jamais d'exception ? 

On considerera que toutes les fonctions appelees et les objets utilises (incluant les 
objets temporaires) sont robustes aux exceptions (c'est-a-dire qu'ils peuvent generer 
des exceptions, mais se comportent correctement dans ce cas-la et, en particulier, ne 
laissent pas de ressources memoires non desallouees). 



Une remarque preliminaire au sujet des hypotheses de travail : nous avons 
considere que toutes les fonctions appelees etaient robustes aux exceptions ; en prati- 
que, ce n'est pas toujours le cas pour les flux. Les fonctions operator<< des classes 
« flux » peuvent en effet avoir des effets secondaires indesirables : il peut tout a fait 
arriver qu'elles traitent une partie de la chaine qui leur est passee en parametre, puis 
echouent sur une exception. Nous negligerons ce type de problemes dans la suite. 

Reprenons le code de la fonction EvaiuerSaiaireEtRenvoyerNom et voyons si 
elle est robuste aux exceptions : 

String EvaiuerSaiaireEtRenvoyerNom) Employe e ) 
{ 

if( e.FonctionO == "PDG" I I e.SalaireO > 100000 ) 
{ 

cout <<e . Prenom ( ) << " " <<e . Norn ( ) <<"est trop paye"<<endl; 

} 

return e. Prenom () + " " + e.Nom(); 

} 

Telle qu'elle est ecrite, cette fonction garantit de ne pas provoquer de fuite 
memoire en presence d'exceptions. En revanche, elle n'assure pas que l'etat du pro- 
gramme sera inchange si une exception se produit (autrement dit, si la fonction 
echoue sur une exception, elle pourra ne s'etre executee que « partiellement »). 

En effet : 

■ Si une exception se produit entre le debut et la fm de la transmission des informa- 
tions a cout (par exemple, si le quatrieme operateur << genere une exception), le 
message n'aura ete que partiellement affiche 1 . 

■ Si le message s'affiche correctement mais qu'une exception se produit lors de la 
suite de 1' execution de la fonction (lors de la preparation de la valeur de retour, par 
exemple), alors la fonction aura affiche un message alors qu'elle ne se sera pas 
executee entierement. 



1. Ce n'est pas dramatique dans le cas d'un message affiche a l'ecran, mais pourrait l'etre 
nettement plus, par exemple, dans le cas d'une transaction bancaire. 
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Enfin, la fonction ne garantit evidemment pas qu'elle ne laissera echapper aucune 
exception, au contraire : chacune des operations effectuees en interne est susceptible 
de generer une exception et il n'y a aucun bloc try /catch ! 



Recommandation 

Connaissez et appliquez les principes generaux garantissant le bon comportement d'un 
programme en presence d'exceptions. 



Tentons maintenant de modifier la fonction de maniere a assurer son caractere ato- 
mique (execution complete ou sans effet, mais pas partielle). 

Voici une premiere proposition : 

// lere proposition : est-ce mieux ? 

String Evaluer SalaireEtRenvoyerNom ( Employe e ) 
{ 

String result = e.Prenom() + " " + e.Nom(); 

if( e.Fonctionf) == "PDG" I I e.SalaireO > 100000 ) 
{ 

String message = result+"est trop paye\n"; 
cout << message; 

} 

return result; 

} 

Cette solution n'est pas mauvaise. Nous limitons totalement le risque d'affichage 
partiel, grace a l'emploi de la variable message et du caractere « \n » au lieu de 
« endi ». II subsiste pourtant un probleme, illustre dans le code client suivant : 

/ / Un probleme 
// 

String leNom ; 

leNom = Evaluer SalaireEtRenvoyerNom ( Robert ) ; 

La fonction renvoyant un objet par valeur, le constructeur de copie de string est 
appele pour copier la valeur retournee dans l'objet « leNom ». Si cette copie echoue, la 
fonction se sera executee mais le resultat aura ete irremediablement perdu ; on ne peut 
done pas considerer qu'il s'agit la d'une fonction atomique. 

Une deuxieme solution serait d'utiliser une reference non constante passee en 
parametre plutot qu'une valeur de retour : 

// 2eme proposition : est-ce la bonne ? 

void EvaluerSalaireEtRenvoyerNom ( Employe e, Strings r ) 
{ 

String result = e.Prenom() + " " + e . Norn ( ) ; 

if( e.FonctionO == "PDG" I I e.SalaireO > 100000 ) 

{ 
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String message = result+"est trop paye\n"; 
cout << message; 

} 

r = result; 

} 

Cette solution peut paraitre meilleure, du fait qu'elle evite 1' utilisation d'une 
valeur de retour et elimine, de ce fait meme, les risques lies a la copie. En realite, elle 
pose exactement le meme probleme que la precedente, deplace a un autre endroit : 
c'est maintenant Foperation d' affectation qui risque d'echouer sur une exception, ce 
qui aura egalement pour consequence une execution partielle de la fonction. 

Pour finalement resoudre le probleme, il faut avoir recours a un pointeur pointant 
vers un objet string alloue dynamiquement ou, mieux encore, a un pointeur automa- 
tique (auto_ptr) : 

// 3eme proposition : la derniere et la bonne ! 
auto_ptr<String> 

EvaluerSalaireEtRenvoyerNom ( Employe e ) 
{ 

auto_ptr<String> result 

= new String (e.Prenom() + " " + e.NomO); 

if( e. Fonction () == "PDG" I I e.SalaireO > 100000 ) 
{ 

String message = result+"est trop paye\n"; 
cout << message; 

} 

return result; // ne risque pas de lancer d' exceptions 

} 

Cette derniere solution est la bonne. II n'y a plus aucun risque de generation 
d' exception au moment de la transmission d'une valeur de retour ou au moment d'une 
affectation. Cette fonction satisfait tout a fait a la technique du « valider ou annuler » : 
si elle est interrompue par une exception, elle annule totalement les operations en 
cours (aucun message affiche a l'ecran, aucune valeur recue par 1' appelant). L' utilisa- 
tion d'un auto_ptr comme valeur de retour permet de gerer correctement la transmis- 
sion de la chaine de caractere a 1' appelant : si 1' appelant recupere correctement la 
valeur de retour, il prendra le controle de la chaine allouee et aura pour responsabilite 
de la desallouer ; si, au contraire, 1' appelant ne recupere pas correctement la valeur de 
retour, la chaine orpheline sera automatiquement detruite au moment de la destruction 
de la variable automatique result. Nous n'avons obtenu cette robustesse aux excep- 
tions qu'au prix d'une petite perte de performance due a 1' allocation dynamique. Les 
benefices retires au niveau de la qualite du code en valent largement la peine. 

Nous avons finalement reussi, avec la troisieme proposition, a obtenir une imple- 
mentation de la fonction se comportant de maniere atomique 1 (c'est-a-dire dont l'exe- 



1. Comme nous 1' avons indique precedemment, nous negligeons ici le fait que les opera- 
teurs sur les flux peuvent generer des exceptions. 
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cution est soit totale, soit sans effet). Ceci a ete possible car nous avons reussi a 
assurer que les deux actions externes (affichage d'une chaine a l'ecran, renvoi d'une 
valeur chaine au code appelant) de la fonction soient executees toutes les deux en cas 
de reussite ou ne soient ni l'une ni 1' autre executees en cas d' exception. 

II n'est pas toujours possible d'arriver a ce resultat, surtout avec des fonctions 
ayant des actions externes trap nombreuses ou trop decouplers (par exemple, une 
fonction realisant une ecriture sur cout puis une ecriture sur cerr poserait probleme). 
Dans ce type de cas, la seule solution viable est souvent la scission de la fonction a 
traiter en plusieurs fonctions. C'est done, une nouvelle fois, l'occasion d'insister sur 
les benefices apportes par une bonne modularite du code. 



Recommandation 

Efforcez-vous de toujours decouper votre code de maniere a ce que chaque unite d'execu- 
tion (chaque module, chaque classe, chaque fonction) ait une responsabilite unique et bien 
definie. 



En conclusion : 

L'obtention d'une robustesse importante aux exceptions ne s'effectue generale- 
ment (mais pas toujours) qu'au prix d'un sacrifice en terme de performances. 

II est general difficile de rendre « atomique » une fonction ayant plusieurs actions 
exterieures. En revanche, le probleme peut etre en general etre resolu par le decoupage 
de la fonction a traiter en plusieurs fonctions. 

II n'est pas toujours indispensable de rendre une fonction parfaitement robuste aux 
exceptions. En l'occurrence, la premiere des trois propositions presentees plus haut 
sera a priori amplement suffisante pour la majorite des utilisateurs et permettra de plus 
d'eviter la legere perte de performance qu'impose la troisieme proposition. 

Derniere petite remarque : dans tout ce probleme, nous avons neglige le fait que la 
fonction operator<< ( ) de la classe ostream puisse ne pas se comporter correctement 
en presence d'exceptions (c'est d'ailleurs le cas pour toutes les classes de type 
« flux »). Notre hypothese initiale selon laquelle toutes les fonctions internes a Eva- 
luerSaiaireEtRenvoyerNom etaient robustes aux exceptions n'etait done pas tout a 
fait pertinente. Pour etre parfaite, notre implementation devrait gerer par un bloc try/ 
catch les exceptions pouvant etre generees par Foperateur << puis les relancer vers 
l'appelant en ayant, au passage, reinitialise le statut d'erreur de l'objet cout. 
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Etes-vous capable de concevoir des classes techniquement solides ? Le but de cet exemple est 
de mettre en exergue les details permettant d'implementer des classes d'un niveau profession- 
nel. plus robustes et plus faciles a maintenir. 

_ 

Etudiez le code suivant. II contient un certain nombre d' imperfections et d'erreurs. 
Lesquelles ? Comment peut-on les ameliorer ? 

class Complex 
{ 

public : 

Complex) double real, double imaginary = 0 ) 
: _real (real) , _imaginary (imaginary) 



void operator+ ( Complex other ) 
_real = _real + other .real ; 

^imaginary = _imaginary + other ._imaginary; 

void operator<< ( ostream os ) 

os << "(" << _real << "," << _imaginary << ")"; 

Complex operator++() 

++_real; 
return *this; 



71 
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Complex operator++ ( int ) 
{ 

Complex temp = *this; 

++_real; 

return temp; 

} 

private : 

double _real, _imaginary; 



Cette classe contient un grand nombre de problemes, qui ne seront d' ailleurs pas 
tous traites ici, le but de cet exemple etant plutot d' aborder les questions relatives a la 
mecanique de la classe (quel est le prototype a utiliser pour l'operateur << ? L'opera- 
teur + doit-il etre une fonction membre ?...) plutot que les details du style de l'imple- 
mentation. 

Avant meme de s'interesser a ces problemes, on peut se demander s'il est vraiment 
opportun de developper une classe complex, alors qu'une classe equivalente existe 
dans la bibliotheque standard du C++. Plutot que de perdre du temps a ameliorer la 
classe complex presentee ici, il serait plus judicieux de reutiliser le modele de classe 
existant (std : : complex) qui a toutes les chances d'etre bien plus exempt d'erreurs et 
plus optimise que notre classe - etant donne le fait qu'il a ete developpe depuis un 
grand nombre d'annees et deja utilise par un grand nombre de developpeurs. 



Recommandation 

Reutilisez le code existant- surtout celui de la librairie standard. C'est plus rapide, plus 
facile et plus sur. 



Cette remarque preliminaire etant faite, interessons-nous tout de meme aux pro- 
blemes de notre classe complex. 

1 . Le constructeur autorise une conversion implicite. 

Complex ( double real, double imaginary = 0 ) 
: _real (real) , _imaginary (imaginary) 

{ 
} 

Son second parametre ayant une valeur par defaut, ce constructeur peut etre utilise 
pour effectuer une conversion implicite de double vers complex. Ca ne prete peut-etre 
pas a consequence dans ce cas, mais, comme nous l'avons vu dans le probleme n° 6, 
les conversions implicites non controlees peuvent induire des problemes. II est prefe- 
rable de prendre l'habitude de specifier par defaut le mot-cle explicit pour un 
constructeur, a moins d'etre certain que la conversion implicite qu'il induit est sans 
risque (voir egalement le probleme n° 19, relatif aux conversions implicites). 
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CONSEIL 

Prenez garde aux variables temporaires generees de maniere cachee par les conversions 
implicites. Pour cela, specifiez, lorsque cela est possible, le mot-cle « explicit » pour les 
constructeurs et evitez d'implementer des operateurs de conversions. 



2. La fonction operator+ n'est pas optimisee. 

void operator+ ( Complex other) 

{ 

_real = _real + other. _real; 

_imaginary = _imaginary + other ._imaginary; 

} 

II aurait fallu, pour une meilleure efficacite, passer une reference constante plutot 
qu'une valeur. 



Recommandation 

Passez les objets par reference constante (consts) plutot que par valeur. 



D'autre part, concernant 1' addition des parties reelles et imaginaires, il aurait ete 
preferable d'utiliser a+=b plutot que a = a+b (le gain de performance n'est pas 
enorme lorsqu'il s'agit de doubles, neanmoins, 1' amelioration peut etre notable pour 
des variables de type objet). 



0 CONSE,L 

Utilisez « a op= b » plutot que « a = a op b » (op designant n'importe quel operateur). 
C'est plus clair et souvent plus efficace. 



L' operateur += est plus efficace car il travaille directement sur l'objet situe a gau- 
che de l'operateur et renvoie uniquement une reference, alors que Foperateur + ren- 
voie un objet temporaire, comme l'indique l'exemple suivant : 

T& T : : operator+= ( const T& other ) 
{ 

//. . . 

return *this; 

} 

const T operator+ ( const TS a, const TS b ) 
{ 

T temp ( a ) ; 
temp += b; 
return temp; 

} 

Notez bien la relation entre les deux operateurs + et +=. Le premier doit faire appel 
au second dans son implementation. Ainsi, le code sera plus simple a ecrire et a main- 
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tenir (les deux operateurs feront la meme chose et la probabilite qu'ils divergent au 
cours de la maintenance sera moindre). 



Recommandation 

Si vous implementez un operateur simple (par exemple, operator), implementez tou- 
jours I'operateur d'affectation correspondant (par exemple, operator+=) et basez I'implemen- 
tation du premier sur le second. D'une maniere generale, deux operateurs op et op= doivent 
toujours se comporter de maniere identique (op designant n'importe quel operateur). 



3. La fonction operator+ ne devrait pas etre une fonction membre. 

void operator+ ( Complex other ) 
{ 

_real = _real + other. _real; 

_imaginary = _imaginary + other ,_imaginary; 

} 

Dans notre exemple, le fait qu'operator+ soit une fonction membre rend impossi- 
ble un certain type d'additions entre complex et double, operations que l'utilisateur 
serait pourtant naturellement tente de faire, etant donne que la classe complex autorise 
les conversions implicites a partir du type double. En effet, s'il est possible d'ecrire 
« a=b+i . 0 », il n'est pas possible d'ecrire « a= l . 0 + b » car la fonction membre 
operator+ attend un complex comme operande situe a gauche du signe +. 

Pour bien faire, il serait plus judicieux de definir deux fonctions globales : 

operator+ (const Complexs, double) et operatort (double, const Complex&),aU 
lieu de la fonction membre definie ici. 



CONSEIL 

Quelques regies pour determiner si un operateur doit etre implements ou non en tant 
que fonction membre : 

• Les operateurs =,(),[] et -> doivent toujours etre des fonctions membres. 

• Les operateurs new, new [ ] , delete et delete [ ] redefinis pour une classe doivent toujours 
etre des fonctions membres statiques de cette classe. 

• Pour toutes les autres fonctions : 

- Si I'operateur a besoin d'une conversion de type pour son operande gauche, s'il s'agit d'un 
operateur s'appliquant a un flux d'entree-sortie (« ou ») ou si I'operateur ne fait appel 
qu'a I'interface publique de la classe, implementez-le en tant que fonction globale (non- 
membre), eventuellement amie (declarees friend), dans les deux premiers cas. 

- Si I'operateur doit avoir un comportement virtuel, ajoutez une fonction virtuelle a la classe 
et implementez I'operateur en tant que fonction membre faisant appel a cette fonction vir- 
tuelle. 

- Sinon, si I'operateur ne rentrant dans aucun des cas precedents, implementez-le en tant 
que fonction membre. 
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4. La fonction operatort ne devrait pas modifier la valeur de l'objet et devrait ren- 
voyer un objet complex temporaire contenant la somme. 

void operatort ( Complex other ) 
{ 

_real = _real + other. _real; 

_imaginary = _imaginary + other ._imaginary; 

} 

Pour etre encore plus precis, cette fonction devrait renvoyer un « const complex » 
(et non pas simplement un « complex »), afin d'interdire les instructions du type 

« a+b=c ». 

5. II faudrait definir la fonction operator+=. En effet, ainsi que nous l'avons men- 
tionne plus haut : « si vous implementez un operateur simple, implementez toujours 
l'operateur d' affectation correspondant ». Etant donne qu'operator+ a ete defini, il 
faudrait done egalement definir operator+= (en basant d'ailleurs son implementation 

SUr celle d'operator+). 

6. La fonction operator<< ne devrait pas etre membre de la classe. 

void operator<< ( ostream os ) 
{ 

os << "(" << _real << "," << _imaginary << ")"; 

} 

La situation est ici similaire au cas de la fonction operatort, traite au point (3). 
Cette fonction devrait plutot etre globale (non membre), avec les parametres suivants : 
« (ostreams, const compiexs) ». En pratique, on definit d'ailleurs generalement 
une fonction membre - souvent virtuelle - nommee Print osur laquelle on base 
1' implementation de la fonction globale operator«. 

Pour bien faire, il faudrait egalement s'assurer que l'operateur << fonctionne avec 
les manipulateurs de formatage classiques de la bibliotheque standard. Referez-vous a 
la documentation de iostream pour plus de details. 

7. La fonction operator« devrait retourner un ostreams, afin d'autoriser le chainage 
d'appel (par exemple : « cout << a << b »). 



Recommandation 

Les fonctions operator<< et operator >> doivent toujours renvoyer une reference vers 
un flux. 



8. Le type de retour de l'operateur de pre-incrementation est incorrect. 

Complex operator++() 
{ 

++_real; 
return *this; 

} 
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Cette fonction devrait renvoyer une reference non constante vers un complex, sous 
peine de provoquer un comportement inattendu de certaines utilisations de l'operateur 
et de penaliser inutilement la performance du code. 

9. Le type de retour de l'operateur de post- incrementation est incorrect. 

Complex operator++ ( int ) 
{ 

Complex temp = *this; 

++_real; 

return temp; 

} 

Cette fonction devrait renvoyer une reference constante vers un complex. En inter- 
disant que l'objet renvoye soit modifie, on s' assure que les instructions du type 
« a++++ », qui ne realisent pas ce a quoi Futilisateur inexperimente s' attend, sont 
interdites par le compilateur. 

10. L' implementation de l'operateur de post- incrementation devrait etre basee sur 
celle de l'operateur de pre-incrementation (voir le probleme n° 6 au sujet de l'imple- 
mentation ideale d'un operateur de post-incrementation). 



Recommandation 

Basez toujours I'implementation de l'operateur de post-incrementation sur celle de l'ope- 
rateur de pre-incrementation, afin de reduire au maximum les risques d'incoherence dans le 
programme. 



1 1 . Evitez d'utiliser des noms reserves 

private : 

double real, ^imaginary ; 

L'habitude, malheureusement parfois conseillee dans certains livres comme Design 
Patterns (Gamma95), consistant a faire debuter les noms des variables membres par un 
caractere souligne {underscore) n'est pas recommandable, car la norme C++ reserve 
justement, pour I'implementation de la bibliotheque standard, certains noms de varia- 
bles ayant cette syntaxe. A moins de connaitre explicitement ces noms reserves afin de 
pouvoir les eviter - tache risquant de s'averer ardue ! - le plus sage est de proscrire l'uti- 
lisation de noms de variables membres commencant par un caractere souligne 1 . En ce 



1 . Le lecteur attentif pourrait arguer ici que les variables reservees commencant par un carac- 
tere souligne sont en 1' occurrence des variables non-membres, et que par consequent cela ne 
pose pas de probleme si le developpeur utilise une syntaxe de ce type pour des variables 
membres. Cette affirmation doit etre nuancee car il subsiste un risque fort lie a l'utilisa- 
tion, dans V implementation de la bibliotheque standard, de macros #def ine portant des 
noms commen§ant par un caractere souligne. Le compilateur ne controlant pas la portee des 
macros, meme une macro ecrite dans le but d'implementer une variable membre peut entrer 
en conflit avec une variable non membre du meme nom. L ideal est done d' eviter systemati- 
quement les caracteres soulignes au debut des noms de variables. 
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qui me conceme, j'ai 1' habitude d'utiliser des noms de variables termines par un carac- 
tere souligne. 

Pour finir, voici une version corrigee de la classe complex, tenant compte de toutes 
les remarques ci-dessus : 

class Complex 
{ 

public : 

explicit Complex ( double real, double imaginary = 0 ) 
: real_(real), imaginary_ (imaginary) 

{ 

} 

ComplexS operator+= ( const ComplexS other ) 

{ 

real_ += other. real_; 
imaginary_ += other . imaginary_; 
return *this; 

} 

Complex& operator++() 

{ 

++real_; 
return *this; 

} 

const Complex operator++ ( int ) 

{ 

Complex temp ( *this ) ; 

++*this; 

return temp; 

} 

ostreamS Print ( ostreamS os ) const 
{ 

return os << "(" << real_ << "," << imaginary_ << ")"; 

} 

private : 

double real_, imaginary_; 

}; 

const Complex operator+ ( const ComplexS lhs, const ComplexS rhs ) 
{ 

Complex ret ( lhs ) ; 
ret += rhs; 
return ret; 



ostreamS operator<< ( ostreamS os, const ComplexS c ) 
{ 

return c . Print (os ) ; 

} 



© copyright Editions Eyrolles 



78 Conception de classes, heritage 



Pb n° 21 . Redefinition de fonctions virtuelles Difficulte : 6 



Le mecanisme des fonctions virtuelles est tres pratique et tres souvent utilise en C++. Nean- 
moins, mal maitrise, il peut occasionner des comportements inattendus pouvant faire perdre 
beaucoup de temps au developpeur inexperimente. Ce probleme vous permet de tester votre 
degre de connaissance des subtilites liees aux fonctions virtuelles. 



Examinez le code suivant, visiblement ecrit par un developpeur voulant tester 
Futilisation des fonctions virtuelles. Quel est, a votre avis, le resultat auquel ce deve- 
loppeur s'attendait ? Quel est le resultat qui va se produire en realite? 



tinclude <iostream> 
#include <complex> 
using namespace std; 
class Base 
{ 

public : 

virtual void f ( int ) ; 
virtual void f ( double ) ; 
virtual void g( int i = 10 ) ; 

}; 

void Base::f( int ) 
{ 

cout << "Base: : f (int) " << endl; 

} 

void Base::f( double ) 
{ 

cout << "Base :: f (double) " << endl; 

} 

void Base::g( int i ) 
{ 

cout << i << endl; 

} 

class Derived: public Base 
{ 

public : 

void f ( complex<double> ) ; 
void g( int i = 20 ); 

}; 

void Derived: :f( complex<double> ) 
{ 

cout << "Der ived :: f ( complex) " << endl; 

} 

void Derived: :g( int i ) 
{ 

cout << "Derived: :g () " << i << endl; 

} 

void main ( ) 
{ 

Base b; 
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Derived d; 

Base* pb = new Derived; 

b.f (1.0) ; 

d.f (1.0) ; 

pb->f (1.0) ; 

b . g ( ) ; 

d . g ( ) ; 

pb->g () ; 

delete pb; 



Avant d'aborder les fonctions virtuelles proprement dites, voyons deja une petite 
remarque de style et une erreur grave. 

1 . « void main ( ) » n'est pas du C++ standard, et done, n'est pas portable. 

void main ( ) 

La fonction main o apparait sous cette forme dans de nombreux ouvrages. Bien 
que certains auteurs indiquent que cette ecriture fait partie integrante du C++ stan- 
dard, ce n'est malheureusement pas le cas - comme cela ne 1' a jamais ete non plus 
pour le C, d'ailleurs. 

Bien que « void main o » ne soit pas une forme autorisee par la norme C++, de 
nombreux compilateurs l'acceptent. Abuser du laxisme des compilateurs de ce type, 
e'est ecrire du code qui risque de ne pas etre portable sur d'autres compilateurs. 
Lideal est done de se limiter aux deux formes officielles - et portables - de main : 

int main ( ) 

int main (int argc, char* argv [ ] ) 

Une petite remarque au sujet de Futilisation de return dans la fonction main ( ) . 
Dans notre exemple, aucune instruction return n'est utilisee - ce qui est normal, etant 
donne que le type de retour de notre fonction est void. Neanmoins, il faut savoir que, 
meme dans le cas d'une fonction maino correcte renvoyant un int, il n'est pas 
obligatoire de retourner explicitement une valeur. La norme C++ specifie qu'en 
l'absence d'instruction return explicite, le compilateur doit tout de meme accepter le 
code et ajouter un « return o » implicite. Ceci etant, il n'est pas recommande de 
prendre cette habitude de programmation car, independamment du fait qu'il peut etre 
utile de renvoyer des codes d'erreurs a 1' appelant, il s'avere qu'en pratique, un grand 
nombre de compilateurs n'implementent pas cette regie et emettent des avertisse- 
ments lorsque aucun return n'est present dans la fonction main ( ) . 

2. « delete pb ; » est une instruction dangereuse. 
delete pb ; 

Cette instruction semble anodine. Elle le serait effectivement si la classe B com- 
portait un destructeur virtuel. Comme ce n'est pas le cas, cette tentative de destruction 
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d'un objet de classe Derived reference par un pointeur de type Base* va faire appel au 
mauvais destructeur - celui de la classe de base - ce qui va avoir pour consequence 
d'appeler l'operateur delete ( ) en specifiant une taille d'objet incorrecte. 



Recommandation 

Dotez systematiquement toute classe de base d'un destructeur virtuel (a moins d'etre 
absolument certain que personne ne tentera jamais de detruire un objet derive, reference a par- 
tir d'un pointeur sur cette classe). 



Passons maintenant aux fonctions virtuelles. Pour cela, precisons avant tout la 
signification de trois termes couramment utilises dans ce contexte : 

■ Surcharger (to overload) une fonction f o signifie definir une nouvelle fonction 
avec le meme nom (f) mais des parametres differents, ay ant la meme portee que 
f O. Lorsqu'une fonction £() est appelee, le compilateur recherche, parmi les 
fonctions disponibles, celle qui correspond le mieux aux parametres fournis. 

■ Redeflnir (to override) une fonction virtuelle f omembre d'une classe signifie 
definir une nouvelle fonction ay ant le meme nom (f) mais des parametres diffe- 
rents dans une classe derivee. 

■ Masquer (to hide) une fonction f ( ) ay ant une portee donnee (classe de base, classe 
exterieure, espace de nommage) signifie definir une nouvelle fonction portant le meme 
nom (f ) mais ayant une portee differente, a partir de laquelle la fonction f ( ) initiale 
sera inaccessible (classe derivee, classe interne, ou autre espace de nommage). 

3. La fonction Derived : : f ( ) masque Base : : f { ) 

void Derived :: f ( complex<double> ) 

La fonction Derived: :f o ne surcharge pas Base: :f o, elle la masque. II est 
important de bien comprendre la difference : dans notre exemple, cela signifie que 
Base: :f (int) et Base: :f (double) ne sont plus visibles lorsqu'on se situe a l'inte- 
rieur de Derived (aussi etonnant que cela puisse paraitre, de nombreux compilateurs, 
meme parmi les plus populaires, n'emettent meme pas d' avertissement pour signaler 
les problemes de ce genre ; c'est done d'autant plus important que nous insistions ici 
sur ce point). 

Si le masquage les fonctions f de Base etait intentionnel, alors le code de l'exem- 
ple est correct 1 . Pour eviter le masquage, souvent source de mauvaises surprises, il 

1 . Bien qu'en general, pour faciliter la lisibilite et la maintenance du code, il soit plus clair, 
lorsqu'on masque deliberement un nom de la classe de base, de le specifier en utilisant 
une instruction using situee dans la partie privee de la classe derivee. 
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faut rendre explicitement les noms de ces fonctions accessibles depuis l'interieur de 

Derived en Utilisant 1'instrUCtion « using Base : : f ». 



Recommandation 

Si vous definissez une fonction membre portant le meme nom qu'une ou plusieurs fonc- 
tions heritees, assurez-vous de rendre accessibles ces fonctions heritees depuis la classe derivee 
en utilisant une declaration de type « using », a moins que vous ne soyez certains de vouloir 
deliberement les masquer. 



4. La fonction Derived: : g ( ) redefinit la fonction Base : : g ( ) mais change la valeur 
par defaut du parametre 

void g(int i = 20) 

Ce n'est vraiment pas une bonne idee ! A moins de vouloir deliberement semer le 
trouble et la confusion, il n'est vraiment pas utile de changer les valeurs par defaut des 
parametres des fonctions heritees que vous redefinissez (d'ailleurs, on peut se deman- 
der si, d'une maniere generale, il ne vaut pas mieux preferer la surcharge de fonctions 
a l'utilisation de parametres par defaut - mais c'est un autre sujet). En conclusion, ce 
code est correct et sera accepte par le compilateur, mais il est vraiment recommande 
d'eviter pareilles pratiques ! Nous verrons un peu plus loin un exemple des 
consequences que la redefinition de cette valeur peut avoir. 



Recommandation 

Ne changez jamais les valeurs par defaut des parametres des fonctions heritees que vous 
redefinissez. 



Penchons-nous a present sur la fonction main ( ) et voyons si elle effectue vraiment 
ce a quoi l'auteur de ces lignes s'attendait : 

void main ( ) 
{ 

Base b; 
Derived d; 

Base* pb = new Derived; 
b.f (1.0) ; 

Pas de probleme. C'est la fonction Base : : f (double) qui est appelee. 
d.f (1.0) ; 

Cette fois, c'est la fonction Derived: : f (compiex<doubie) qui est appelee, et non 
pas, comme certains auraient pu s'y attendre, la fonction Base : : f (double) . Pourquoi, 
a votre avis ? Souvenez-vous de ce que nous avons vu plus haut : la classe Derived ne 
contient pas de declaration « using Base : : f ( ) » ; par consequent, le fait de definir la 

fonction Derived: : f ( complex<double> ) masque les fonctions Base : : i (int) et 

Base : : f (double) . Ces fonctions sont done hors de la portee de la classe Derived et 
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ne sont pas prises en compte par l'algorithme de surcharge effectuant le choix de la 
meilleure fonction f . 

La classe compiex<doubie> implementant une conversion implicite depuis le 
type double, notre exemple n'est en que plus trompeur : le fait que la 
fonction Base : : f (double) soit masquee ne provoque aucune erreur de compilation 
lorsque le developpeur, pensant l'appeler, ecrit « d. f (i . 0) ». En effet, la conversion 
implicite aidant, le compilateur interprete cet appel de la maniere suivante : 
« Derived: : f ( complex<double> (1.0)) ». 

pb->f (1.0); 

Bien que pb soit un pointeur de type Base* pointant vers un objet Derived, c'est la 
fonction Base : : f (double) qui est appelee. Le fait que cette fonction soit virtuelle ne 
change rien, la resolution des noms s'effectuant parmi les fonctions declarees dans 
Base (le type statique ou type du pointeur) et non dans Derived (le type dynamique ou 
type du «pointe»). En l'absence de fonction Derived: : f (double) , c'est done la 
fonction correspondante de Base qui est appelee. Dans le meme ordre d'idee, 
l'appel « pb->f (compiex<doubie> (l.o)) ; » provoquerait une erreur de compilation 
car il n'y a pas fonction correspondante dans la classe Base. 

b.g() ; 

Affiche « l o », valeur par defaut de la fonction Base : : g ( int ) . Pas de surprise. 
d.g() ; 

Affiche « Derived: :g () 2 0 », Valeur par defaut de la fonction Derived: :g (int) . 

Pas de surprise non plus. 
pb->g() ; 

Affiche « Derived ::g() 10 ». 

Cela merite un petit commentaire. Ce serait done la fonction Derived : g ( int ) qui 
serait appelee, mais avec le parametre par defaut de Base :: g ( int ) ! Aussi etrange que 
cela puisse paraitre, c'est effectivement ce qui se produit 1 . En effet, comme pour la 
resolution des noms, c'est le type statique qui est pris en compte par le compilateur 
pour les parametres par defaut. II est done normal qu'on obtienne ici la valeur « 10 ». 
En revanche, comme Base: :g (int) est virtuelle, c'est bien la fonction Deri- 
ved : g ( int ) qui est appelee. 

Si vous avez bien compris ces derniers paragraphes, et notamment tout ce qui 
concerne le masquage des fonctions et les roles respectifs des types statique et dyna- 
mique, alors vous avez une bonne maitrise du mecanisme des fonctions virtuelles. 
Felicitations ! 

delete pb ; 



1. Bien qu'on puisse, encore une fois, blamer l'auteur de la classe Derived pour son choix 
inepte de changer la valeur par defaut du parametre lors de la redefinition de g ( ) . 
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Pour finir, cette instruction n'effectue pas correctement la deallocation de l'objet 
vers lequel pointe pb, car le destructeur de Base n'est pas virtuel - se referer au debut 
de la solution, ou ce point a ete vu en detail. 



Pb n° 22. Relations entre classes (1 re partie) Difficulte : 5 



Nous aborderons dans ce probleme une faute de conception, malheureusement couramment com- 
mise par de trap nombreux developpeurs. 



Une application reseau utilise deux types de sessions de communication, dont 
chacune utilise un protocole particulier. Les deux protocoles presentent un certain 
nombre de similarites (certaines operations et meme certains messages leur sont com- 
muns). Le developpeur a done decide de rassembler ces operations et messages com- 
muns dans une classe de base BasicProtocoi : 

class BasicProtocoi 
{ 

public : 

BasicProtocoi () ; 
virtual -BasicProtocoi () ; 
bool BasicMsgA( /*...*/ ); 
bool BasicMsgB( /*...*/ ); 
bool BasicMsgC( /*...*/ ); 

}; 

class Protocoll : public BasicProtocoi 
{ 

public : 

Protocoll () ; 
-Protocoll () ; 
bool DoMsgl ( /*...*/ ) ; 
bool DoMsg2 ( /*...*/ ) ; 
bool DoMsg3 ( /*...*/ ) ; 
bool DoMsg4 ( /*...*/ ) ; 

}; 

class Protocol2 : public BasicProtocoi 
{ 

public : 

Protocol2 () ; 
~Protocol2 () ; 
bool DoMsgl ( /*...*/ ) ; 
bool DoMsg2 ( /*...*/ ) ; 
bool DoMsg3 ( /*...*/ ) ; 
bool DoMsg4 ( /*...*/ ) ; 
bool DoMsg5 ( /*...*/ ) ; 

}; 
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Les fonctions DoMsg . . . ( ) sous-traitent leur travail, autant que faire se peut, aux 
fonctions BasicProtocoi : :Basic(), mais effectuent elles-memes les transmissions 
de message. Chaque classe pourrait avoir des membres supplementaires, mais ce n'est 
pas le sujet de ce probleme. 

Commentez ce code, notamment au niveau des relations entre les classes. Argu- 
mentez vos remarques. 




Le code ci-dessus presente un defaut majeur, malheureusement trop frequemment 
rencontre, au niveau de la conception des relations entre classes. 

Recapitulons les donnees du probleme : les classes Protocoii et Protocoi2 deri- 
vent toutes les deux, de maniere publique, de la classe BasicProtocoi, dont elles uti- 
lisent les fonctions, comme le precise l'enonce : 

Les fonctions DoMsg . . . ( ) sous-traitent leur travail, autant que faire se peut, 
aux fonctions BasicProtocoi: :Basic(), mais effectuent elles-memes les 
transmissions de message. 

Autrement dit, les classes Protocoii et Protocoi2 font appel a la classe Basic- 
Protocol dans leur implementation. Cette relation de type « EST-IMPLEMENTE- 
EN-FONCTION-DE » devrait se traduire, en C++, par 1' utilisation d'une derivation 
privee ou d'un objet membre (composition). Malheureusement, de trop nombreux 
developpeurs choisissent dans ce cas d'effectuer une derivation publique, preuve 
qu'ils effectuent une confusion entre heriter d'une implementation et heriter d'une 
interface, alors que ce sont deux concepts bien distincts. 



Recommandation 

N'abusez pas du mecanisme de derivation publique. Ce type de derivation doit etre 
reserve aux cas ou la relation entre classe derivee et classe de base est de type « EST-UN » ou 
« FONCTIONNE-COMME-UN », au sens du principe de substitution de Liskov. 



Cette mauvaise habitude qui consiste a utiliser une derivation publique pour heri- 
ter d'une implementation finit par donner naissance a de gigantesques hierarchies de 
classes, dont la maintenance est complexe et 1' utilisation malaisee - les utilisateurs 
souhaitant utiliser une classe derivee bien determinee se voyant obliges d'apprendre 
les interfaces des nombreuses classes de base. Sans compter l'utilisation accrue de la 
memoire due a l'ajout de nombreuses « vtables » (tables de fonctions virtuelles) et 
1' impact sur les performances du aux nombreuses indirections lors des appels des 
fonctions virtuelles. Ayez a 1' esprit ces quelques paragraphes chaque fois que vous 
concevez un programme C++ : les lourdes hierarchies de classes sont une mauvaise 
habitude; rarement necessaires, elles presentent generalement plus d'inconvenients 
que d'avantages. Ne soyez pas victime du discours selon lequel « la programmation 
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orientee objet repose avant tout sur la notion d'heritage ». A titre de contre exemple, 
etudiez 1' architecture de la bibliotheque standard et vous verrez. 



Recommandation 

N'utilisez pas I'heritage public pour reutiliser le code de la classe de base; utilisez I'heritage 
public pour etre reutilise par des objets externes utilisant le polymorphisme de la classe de 
base. 3 



a Je remercie Marshall Cline, co-auteur du desormais classique C+ + FAQs (Cline 95), a quij'ai 
emprunte ce conseil. 

Voici d'ailleurs divers indices qui prouvent bien l'existence d'un defaut de 
conception : 

1. BasicProtocoi n'a pas de fonctions virtuelles (a part le destructeur, dont nous 
parlerons plus loin). 1 Ceci indique que cette classe n'est pas concue pour etre utilisee 
de maniere polymorphique, ce qui limite grandement l'interet d'une derivation publi- 
que a partir de cette classe. 

2. BasicProtocoi n'a aucun membre protege, autrement dit, elle n'a aucune 
« interface de derivation », ce qui limite grandement l'interet d'une derivation a partir 
de cette classe, quelle qu'elle soit d'ailleurs (publique ou privee). 

3. BasicProtocoi implemente un certain nombre de fonctionnalites utilisees par les 
classes derivees. En revanche, elle n'effectue pas le meme type de travail que ses deri- 
vees puisque, comme 1' indique l'enonce, elle ne realise pas de transmission de messa- 
ges. Autrement dit, la relation entre un objet BasicProtocoi et un objet Protocol 
n'est ni du type FONCTIONNE-COMME ni du type EST-UTILISABLE-EN-TANT- 
QUE. L' heritage public ne doit etre utilise que dans un cas et un seul : la modelisation 
d'une relation EST-UN obeissant au principe de substitution de Liskov (c'est-a-dire 
FONCTIONNE-COMME ou EST-UTILISABLE-EN-TANT-QUE). 2 

4. Les classes Protocoii et Protocoi2 font uniquement appel a l'interface publique 
de BasicProtocoi. En d'autres termes, elles n'exploitent pas du tout leur caractere de 
classe derivee et pourraient tout aussi bien utiliser BasicProtocoi sous la forme d'un 
objet externe. 



1. Meme si BasicProtocoi etait elle-meme derivee d'une autre classe de base contenant, 
elle, des fonctions virtuelles, nous serions arrive a la meme conclusion : c'est cette 
autre classe de base qui aurait pu etre utilisee de maniere polymorphique et c'est done 
de cette classe qu'il aurait fallu, dans ce cas, deriver les classes Protocol. 

2. II faut reconnaitre qu'il n'est pas toujours necessaire d'adopter l'approche puriste « une 
responsabilite par classe » et que, parfois, en effectuant une derivation publique depuis 
une classe de base pour heriter d'une interface, on herite egalement d'une implementa- 
tion. Neanmoins, cette approche est pratiquement toujours possible a realiser (voir le 
probleme suivant). 
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En conclusion, BasicProtocoi n'est clairement pas congue pour servir de classe 
de base. Par consequent, il serait plus judicieux de lui donner un nom du type 

MessageCreator OU MessageHelper, d'oter au destmcteur Son attribut « virtual » et 

de revoir la relation de cette classe avec les classes Protocol. Pour modeliser cette 
relation (« EST-IMPLEMENTE-EN-FONCTION-DE »), il y a deux possibilites : 
heritage prive ou objet membre (composition). Laquelle choisir ? La reponse est 
claire : 



Recommandation 

Pour modeliser une relation du type « EST-IMPLEMENTE-EN-FONCTION-DE », preferez 
systematiquement I'utilisation d'un objet membre (composition). N'utilisez I'heritage prive que 
lorsque c'est absolument necessaire - besoin d'acceder aux membres proteges ou de redefinir 
des fonctions virtuelles. N'utilisez jamais I'heritage public pour reutiliser un code existant. 



L'utilisation d'objets membres simplifie la relation entre classes - la classe 
« cliente » n'ayant acces qu'a l'interface publique de la classe « serveur ». Prenez 
1' habitude d'eviter I'heritage lorsqu'il n'est pas indispensable. Votre code n'en sera 
que plus clair et facile a lire - autrement dit, moins cher a maintenir. 



Pb n° 23. Relations entre classes (2 e partie) Difficulte : 6 



Les schemas de conception (design patterns) jouent un role important dans I'ecriture de code 
reutilisable. Saurez-vous reconnaitre, et eventuellement ameliorer, les schemas de conception 
utilises dans ce probleme ? 



Considerons un programme manipulant une base de donnees, qui effectue fre- 
quemment des operations sur tous les enregistrements (ou sur un ensemble d'enregis- 
trements) de tables de la base. Le programme fonctionne de la maniere suivante : il 
effectue une premiere passe, en lecture seule, sur Fensemble de la table, afin d'etablir 
la liste des enregistrements a traiter. Puis, s'appuyant sur cette liste, conservee en 
memoire, il effectue une deuxieme passe pour realiser effectivement les operations sur 
les enregistrements concernes. 

Le developpeur ay ant realise ce programme s'est appuye sur une classe abstraite 
GenericTabieAigorithm, qui fournit un canevas reutilisable pour chacune des opera- 
tions faites sur les tables : cette classe implemente la logique des deux passes - la pre- 
miere etablissant une liste d'enregistrements a traiter, la seconde parcourant cette liste 
en effectuant des operations sur ces enregistrements. Les fonctions specifiques a cha- 
que manipulation de la base (suivant quels criteres determiner si un enregistrement est 
a traiter ou non, quelle operation realiser sur chaque enregistrement) sont implemen- 
tees dans autant de classes derivees de cette classe abstraite. 
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// 

// Fichier gta.h (GenericTableAlgorithm) 

// 

class GenericTableAlgorithm 
{ 

public : 

Gener icTableAlgorithm ( const strings table ); 
virtual ~GenericTableAlgorithm ( ) ; 

//La fonction Process () parcourt tous les enregistrements 
// de la table, appelant la fonction Filter () pour chacun, 
// afin de determiner s'il doit etre traite ou non. 
// Puis, dans une deuxieme passe, elle appelle ProcessRowO 
// pour chacun des enregistrements de la liste etablie 
// lors de la premiere passe. 

// Elle renvoie « true » si le traitement s'est bien passe, 
bool Process ( ) ; 
private : 

// La fonction Filterf) examine si 1' enregistrement 
// passe en parametre est a traiter ou non. 
// Le comportement par defaut est de renvoyer « true » 
// (inclusion de tous les enregistrements) 

// 

virtual bool Filter ( const Records ) ; 

//La fonction ProcessRowO est appelee pour chacun 

// des enregistrements devant etre traites. 

// Cette fonction etant virtuelle pure, elle doit 

// obligatoire etre redefinie dans les classes derivees, 

// qui implementent les details de 1' operation a realiser. 

// (Note: avec cette architecture, chaque enregistrement 

// a traiter sera done lu deux fois; ce n'est peut etre 

// pas optimal du point de vue des performances, mais, 

// pour l'exercice, considerons que e'est necessaire) 

virtual bool ProcessRow ( const PrimaryKeyS ) =0; 

struct GenericTableAlgorithmlmpl * pimpl_; // Implementation 

}; 

Voici un exemple de code client creant et utilisant une classe derivee de Generic- 
TableAlgorithm : 

class MonAlgorithme : public GenericTableAlgorithm 
{ 

// ... Redefinir Filter () and ProcessRowO afin 
// d' implementer des operations specif iques .. . 

}; 

int main ( ) 
{ 
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MonAlgorithme a( "Client" ); 
a . Process ( ) ; 

} 

1. Ce programme, relativement bien concu, implemente un schema de conception 
bien connu. Lequel ? En quoi est-il utile ici ? 

2. Commentez la maniere dont le passage de la conception - qu'on ne remettra pas 
en cause - a 1' implementation a ete realise. L'auriez-vous realise differemment ? Quel 
est le role de l'objet membre pimpi_? 

3. A bien y reflechir, 1' architecture de ce programme pourrait etre amelioree. Quels 
sont les roles joues par GenericTabieAigorithm ? S'ils sont multiples, ne pourrait-on 
pas les implementer dans plusieurs classes ? Quelles consequences cela aurait-il sur la 
reutilisabilite et l'extensibilite de ces classes ? 



Prenons les questions dans l'ordre : 

1. Ce programme, relativement bien congu, implemente un schema de conception 
bien connu. Lequel ? En quoi est-il utile ici ? 

Le schema implemente ici est la « Methode du Modele » (Template Method) 
[Gamma95], qui, rappelons-le, n'a aucun lien avec les modeles C++. Ce schema est 
utile dans les cas ou il s'agit d'implementer des operations suivant toujours le meme 
ordre d' execution et pour lesquelles seule la teneur varie, les details de chaque opera- 
tion specifique etant implemented dans des classes derivees. Ce schema peut etre 
repete a plusieurs niveaux d'une hierarchie de classes, une classe derivee faisant elle- 
meme appel, dans 1' implementation de ses fonctions virtuelles, a des nouvelles fonc- 
tions virtuelles devant etre redefinies dans une classe derivee de niveau inferieur. 

Remarque : on aurait pu egalement noter que la technique du « Pimpl » egalement 
utilisee ici, est en partie similaire au schema de conception « Methode du Pont » (Bri- 
gde Method). Neanmoins, le « Pimpl » de notre exemple est utilise uniquement a des 
fins de masquage de 1' implementation de la classe GenericTabieAigorithm (pare-feu 
logiciel), et non pas en tant que « pont ». La technique du « Pimpl » sera etudiee en 
detail dans les problemes 26 a 30. 



Recommandations 

Evitez d'utiliser des fonctions virtuelles publiques; preferez I'utilisation de la « Methode du 
Modele » (Template Method). 

Apprenez a connaitre et a utiliser les schemas de conception. 
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2. Commentez la maniere dont le passage de la conception - qu'on ne remettra pas 
en cause - a 1' implementation a ete realise. L'auriez-vous realise differemment ? Quel 
est le role de l'objet membre pimpi_? 

Pour les fonctions realisant un traitement, il a ete choisi d'utiliser des codes de 
retour de type booi. C'est peut etre suffisant dans ce cas, mais il faut noter que pour 
reporter des erreurs a 1' appelant, il est souvent preferable d'utiliser soit un code de 
retour pouvant contenir plusieurs valeurs, soit, encore mieux, une exception. 

Le pointeur membre « pimpi_ », au nom intentionnellement prononcable, masque 
1' implementation de la partie interne de la classe. II pointera vers une classe interne 
GenericTabieAigorithmimpi contenant les variables et fonctions privees de la classe 
GenericTabieAigorithm. Ainsi, on evite de recompiler inutilement le code client 
lorsqu'une modification est apportee a la partie privee de la classe. Cette technique 
tres utile, documentee entre autres par Lakos (Lakos96), permet, au prix d'une modifi- 
cation mineure du code, d'augmenter considerablement la modularity de ce code. 



Recommandation 

Lorsque vous implementez une classe destinee a etre largement utilisee, utilisez la techni- 
que du pare-feu logiciel (ou technique du « Pimpl ») afin de masquer la partie privee de la 
classe. Pour cela, declarez un pointeur membre « struct xxxximpi* pimpi_ », vers une struc- 
ture qui sera definie dans ['implementation de la classe et contiendra les variables et fonctions 

membres prives. Par exemple :« class Map { private : struct Maplmpl* pimpl_; }; ». 



3. A bien y reflechir, 1' architecture de ce programme pourrait etre amelioree. Quels 
sont les roles joues par GenericTabieAigorithm ? S'ils sont multiples, ne pourrait-on 
pas les implementer dans plusieurs classes ? Quelles consequences cela aurait-il sur la 
reutilisabilite et l'extensibilite de ces classes ? 

Ce programme pourrait etre ameliore sur un point bien precis. Actuellement, la 

classe GenericTabieAigorithm effectue deUX taches : 

■ d'une part, elle fournit une interface publique destinee a etre utilisee par le code 
client. 

■ d' autre part, elle fournit une interface abstraite destinee a etre implementee par des 
classes derivees specialisees. 

Ces deux taches etant tout a fait independantes l'une de 1' autre, il est preferable de 
les confier a deux classes separees. 



Recommandation 

Dans la mesure du possible, attribuez a chaque entite de votre code - chaque module, 
chaque classe, chaque fonction - une tache unique et clairement definie. 
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Voici ce que donnerait le code avec deux classes separees : 

// 

// Fichier gta.h (GenericTableAlgorithm) 

// 

// Tache n° 1 : Fournir une interface publique 

// a 1' usage des utilisateurs externes de cette classe. 

// Cette tache etant totalement independante de la notion 

// d'heritage, il est preferable de 1' implementer 

// dans une classe specif ique qui n'est pas destinee 

// a etre utilisee comme classe de base. 

// 

class GTAClient; 

class GenericTableAlgorithm 
{ 

public : 

// Le constructeur prend maintenant en parametre 

// une classe contenant 1' implementation des operations 

// a effectuer sur la base. 

// 

GenericTableAlgorithm) const strings table, 

GTAClientS worker ) ; 

// Cette classe n' etant pas destinee a servir de classe 
// de base, il n'est plus necessaire d'avoir un 
// destructeur virtuel 
// 

~GenericTableAlgorithm ( ) ; 
bool Process (); // inchangee 
private : 

struct GenericTableAlgor ithmlmpl * pimpl_; // Implementation 

}; 

// 

// Fichier gtaclient.h 

// 

// Tache n° 2 : Fournir une interface abstraite 

// qui sera implementee par des classes derivees. 

// Cette tache etant totalement decouplee 

// de 1' utilisation de la classe GenericTableAlgorithm 

// par des client externes, il est preferable 

// de 1' implementer dans une classe separee, 

// dont le role sera de servir de classe de base. 

// Les classes derivees, realisant 1' implementation des 

// operations sur les donnees, seront utilisees 

// par la classe GenericTableAlgorithm. 

// 

class GTAClient 
{ 
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public : 

virtual -GTAClient () =0; 

virtual bool Filter ( const Records ) ; 

virtual bool ProcessRow ( const PrimaryKeyS ) =0; 

}; 

// 

// Fichier gtaclient . cpp 

// 

bool GTAClient :: Filter ( const Records ) 
{ 

return true; 

} 

II est preferable que ces deux nouvelles classes soient definies dans deux fichiers 
en-tete separes. 

Voici a quoi ressemble le code du client, apres application de ces changements : 

class MaClasseUtilitaire : public GTAClient 
{ 

// ... Redefinir Filter () and ProcessRow () afin 
// d' implementer des operations specif iques .. . 

}; 

int main ( ) 
{ 

GenericTableAlgorithm a ( "Client", MaClasseUtilitaire ( ) ) ; 
a . Process ( ) ; 

} 

Ceci peut paraitre tres similaire a la version precedente; neanmoins, trois amelio- 
rations ont ete apportees : 

1. L' interface publique de GenericTableAlgorithm est isolee du reste du pro- 
gramme : en particulier, si un nouveau membre public lui est ajoute, il n'est pas neces- 
saire de recompiler les fonctions implementant les operations sur la base de donnees, 
comme c'etait le cas dans la version precedente. 

2. L' interface abstraite declarant les operations sur la base de donnees est, elle aussi, 
isolee du reste du programme : si une modification est apportee a cette interface, il 
n'est pas necessaire de recompiler les programmes client utilisant GenericTableAl- 
gorithm, comme c'etait le cas dans la version precedente. 

3. Les classes implementant les operations sur les donnees pourront, si necessaire, 
etre reutilisees depuis tout classe « algorithme » faisant appel aux fonctions Filter ( ) 

et ProcessRow ( ) - et non plus uniquement depuis GenericTableAlgorithm. 

En resume, garder a l'esprit la regie d'or de l'informatique selon laquelle « il n'y a 
pratiquement aucun probleme qui ne puisse se resoudre par l'ajout d'un niveau 
d' indirection », tout en veillant constamment a ne pas rendre les choses plus comple- 
xes que necessaires, vous permettra generalement de produire un code plus modulaire 
et done, plus facile a reutiliser et a maintenir. 
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Voyons pour finir deux ou trois points relatifs a la genericite en general. 

On pourrait encore faire evoluer la classe GenericTabieAigorithm en remplacant 
la fonction membre Process o par une fonction operator o oeffectuant le meme 
traitement, cette classe effectuant une operation unique. Mieux encore, on pourrait 
purement simplement remplacer la classe GenericTabieAigorithm par une fonction 
du meme nom, pour la bonne raison qu'il n'y a aucun besoin de conserver un contexte 
entre deux appels successifs a Process ( ) , done aucun besoin d'instances separees de 

GenericTabieAigorithm '. 

bool Gener icTableAlgorithm ( 
const strings table, 
GTAClientS method 
) 

{ 

// ... mettre ici le code precedemment contenu dans Process () 

} 

int main ( ) 
{ 

GenericTabieAigorithm ( "Client", MaClasseUtilitaire ( ) ); 

} 

Nous obtenons done ici une fonction dont le comportement est specialise par la 
classe passee en parametre. Mieux encore, sachant que les objets method ne 
contiennent que des fonctions virtuelles, a 1' exclusion de variables membres, et que 
done toutes leurs instances sont fonctionnellement equivalentes, on peut transformer 

GenericTabieAigorithm en modele de fonction : 

template<typename ClasseUtilitaire> 

bool GenericTableAlgor ithm ( const strings table ) 
{ 

// ... mettre ici le code precedemment contenu dans Process () 

} 



int main ( ) 
{ 

GenericTableAlgorithm<MaClasseUtilitaire> ( "Customer" ) ; 

} 

Nous aboutissons done ici, pour finir, a une fonction generique. C'est probable- 
ment 1' implementation la plus adequate dans le cas du probleme qui nous interesse. 
Neanmoins, il faut eviter de tomber dans le piege de la genericite excessive, dont on 
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abuse parfois sous pretexte de vouloir simplifier le code client, ce qui n'est pas une 
raison suffisante en soi. 



Pb n° 24. Utiliser l'heritage sans en abuser Difficulte : 6 



« Quand utiliser l'heritage ? » 

L'heritage est une fonctionnalite du C++ souvent utilisee de maniere abusive, meme par des 
developpeurs experimentes. II est recommande de toujours minimiser le couplage entre clas- 
ses : lorsqu'il y a plusieurs manieres d'implementer une relation entre classes, il faut systemati- 
quement choisir celle qui cree la dependance la plus faible. L'heritage est une des relations les 
plus fortes que Ton puisse creer en C++ (avec la relation d'amitie) : il faut vraiment la reserver 
aux cas ou il n'y a pas d'autre choix. 

Dans ce probleme, nous aborderons les differents types d'heritage : l'heritage prive, meconnu, 
l'heritage protege, rare, pour lequel nous etudions un cas concret d'utilisation et enfin l'heritage 
public, tres employe, pour lequel nous preciserons quand il doit vraiment etre utilise. Au pas- 
sage, nous etablirons la listes des raisons souvent invoquees pour justifier I'emploi d'une relation 
d'heritage et nous verrons lesquelles sont valables et lesquelles ne le sont pas. 

Le modele de classe ci-dessous permet de gerer une liste d' elements (notamment 
l'ajout d'un element et la recuperation de la valeur d'un element) 

// Exemple 1 

// 

template <class T> 
class Liste 

{ 

public : 

bool Insert ( const T&, size_t index ) ; 
T Access ( size_t index ) const; 

size_t SizeO const; 
private : 

T* buf_; 
size_t bufsize_; 

}; 

Considerez maintenant le code ci-dessous, qui montre deux manieres d'implemen- 
ter une classe MaListe basee sur le modele de classe Liste : 

// Exemple 1 (a) 

// 

template <class T> 

class MaListel : private Liste<T> 

{ 

public : 

bool Add ( const T& ); // appelle Insert () 
T Get ( size_t index ) const; 

// appelle Access () 
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using MyList<T> : : Size; 
//. . . 

}; 

// Exemple 1 (b) 
// 

template <class T> 
class MaListe2 
{ 

public : 

bool Add ( const T& ) ; // appelle impl_. Insert ( ) 
T Get ( size_t index ) const; 

// appelle impl_. Access ( ) 
size_t SizeO const; // appelle impl_. Size ( ) ; 
//. . . 
private : 

MyList<T> impl_; 

}; 

Comparez ces deux propositions, en repondant notamment aux questions 
suivantes : 

■ Quelles sont les differences entre MaListei et MaListe2 ? 

■ D'une maniere plus generale, quelles sont les differences entre heritage non-public 
(prive ou protege) et composition ? Etablissez une liste de raisons pouvant justifier 
l'emploi de l'heritage non-public plutot que la composition. 

■ Quelle est la meilleure version : MaListei ou MaListe2 ? 

■ Pour finir et en se replacant dans un contexte general, etablissez la liste des cas 
pour lesquels vous utiliseriez l'heritage public. 




Ce probleme aborde diverses questions relatives a l'heritage, notamment le choix 
entre heritage non-public (prive ou protege) et composition. 

La reponse a la premiere question (« Quelles sont les differences entre MaListei et 
MaListe2 ? ») est relativement simple : il n'y a aucune difference notable entre 
MaListei et MaListe2 ; ces deux classes sont fonctionnellement identiques. 

La deuxieme question permet de rentrer un peu plus dans le vif du sujet : « D'une 
maniere plus generale, quelles sont les differences entre heritage prive et composi- 
tion? Etablissez une liste de raisons pouvant justifier l'emploi de l'heritage non-public 
(prive ou protege) plutot que la composition » 

■ L'heritage non-public (prive ou protege) devrait toujours etre utilise pour traduire 
une relation du type « EST-IMPLEMENTE-EN-FONCTION-DE » (sauf dans un 
cas tres particulier que nous detaillons un peu plus loin). II rend la classe utilisa- 
trice dependante des parties publique et protegee de la classe utilisee. 
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■ La composition traduit toujours une relation du type « A-UN », et done « EST- 
IMPLEMENTE-EN-FONCTION-DE ». Elle rend la classe utilisatrice unique- 
ment dependante de la partie publique de la classe utilisee. 

II est facile de demontrer que la composition est un sous-ensemble de I'heritage, 
e'est-a-dire qu'il n'y a rien qu'on puisse faire avec un objet membre Liste<T> et qui 
ne puisse pas etre fait avec une classe derive de Liste<T>. D'un autre cote, avec 
I'heritage, nous sommes limites a un seul objet Liste<T> (l'objet de base), alors qu'en 
utilisant la composition, il est possible d' avoir plusieurs instances de Liste<T>. 



Recommandation 

Pour implementer une relation du type « EST-IMPLEMENTE-EN-FONCTION-DE », preferez 
I'utilisation de la composition a celle de I'heritage. 



D'une maniere plus generate, quelles fonctionnalites supplementaires apporte 
I'heritage non-public par rapport a I'utilisation de la composition ? Autrement dit, 
quels sont les cas ou Femploi de I'heritage non-public est necessaire ? En voici un 
certain nombre, classes par frequence decroissante : 

■ Besoin de redeflnir des functions virtuelles. Lorsque la classe utilisee comporte 
des fonctions virtuelles pouvant etre specialisees par la classe utilisatrice, I'heri- 
tage se justifie. C'est d'ailleurs la principale raison d'etre du mecanisme d'heri- 
tage. Dans le cas ou la classe utilisee serait abstraite (si elle comporte au moins 
une fonction virtuelle pure), la creation d'une classe derivee est obligatoire 
puisqu'on ne peut pas creer d' instance de la classe utilisee. 

■ Besoin d'acceder a des membres proteges. La classe utilisatrice a besoin de faire 
appel a une ou plusieurs fonctions membres protegees 1 . Se justifie, en particulier 
lorsque la classe utilisee comporte un constructeur protege devant etre appelee par 
la classe utilisatrice. 

■ Besoin de construire l'objet « utilise » avant un autre objet de base (et/ou de 
le detruire apres). Dans le cas specifique ou la classe utilisatrice a elle-meme une 
classe de base dont les instances doivent etre construites apres (et detruites avant) 
l'objet « utilise », I'heritage est la seule solution possible. Ce type de besoin peut 
se produire, par exemple, lorsque l'objet « utilise » maintient un verrou (section 
critique, transaction de base de donnees, ...) qui doit couvrir l'integralite de la 
duree de vie d'un objet de base de l'objet utilisateur. 

■ Besoin de partager une classe de base virtuelle ou de redeflnir le constructeur 
d'une classe de base virtuelle. Lorsque la classe utilisee a une classe de base vir- 
tuelle et que la classe utilisatrice souhaite, soit heriter de cette classe de base, soit 



1. Je dis « fonctions membres » car, bien entendu, il serait tout a fait maladroit d'implemen- 
ter une classe comportant des variables membres publiques ou protegees, bien qu'on 
puisse rencontrer de telles pratiques dans certains exemples de code bien maladroits. 
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specialiser la construction de cette classe de base 1 , il est indispensable de faire 
deliver la classe utilisatrice de la classe derivee. 

■ Optimisation des performances par l'emploi d'une « classe de base vide ». 

Lorsque la classe « utilisee » ne comporte que des fonctions membres (et done 
aucune variable membre), le fait d'utiliser l'heritage a la place de la composition 
peut permettre d'economiser de l'espace memoire, en vertu du principe de la 
« classe de base vide ». Ce principe autorise les compilateurs a ne reserver aucun 
espace memoire pour une classe de base ne contenant que des fonctions membres, 
alors qu'ils sont obliges d'allouer un espace memoire non nul pour tout objet 
membre, mais lorsque celui-ci ne contient aucune variable membre. 

class B { /* ... ne contient que des fonctions membres... */ ); 

// Composition : occupation d' espace memoire superflu 
// 

class D 
{ 

B b_; // b_ occupera au moins un octet en memoire, 
}; // meme si B est une classe vide 

// Heritage : limite 1' occupation d' espace memoire superflu 
// 

class D : private B 

{ // 1' objet de base B peut n'occuper 

}; // aucune place en memoire 

Pour plus de details, voir l'excellent article de Nathan Myers sur ce sujet dans Dr. 
Dobb's Journal (Myers97). 

Pour etre realiste, cette optimisation - qui n'est d'ailleurs pas implementee par 
tous les compilateurs - n'apporte pas grand chose : il faut veritablement qu'il y ait un 
nombre enorme d'instances creees (disons, quelques dizaines de milliers) pour qu'elle 
presente un interet pratique. II n'est en general pas judicieux d'introduire une relation 
d' heritage - et par la-meme un couplage fort entre classes - uniquement pour profiter 
de cette optimisation (a moins d'etre certain que votre compilateur l'implemente et 
que le nombre d'objets alloues par votre programme est suffisamment important pour 
que vous en retiriez un avantage certain). 

II existe un cas supplemental qui peut justifier le recours a une derivation non 
publique (au passage, e'est le seul qui ne traduise pas une relation du type « EST- 
IMPLEMENTE-EN-FONCTION-DE » ) : 

■ Mise en oeuvre de « polymorphisme partiel » (implementation d'un certain 
type de relation « EST-UN »). Pour implementer une relation « EST- UN » au 
sens du principe de substitution de Liskov 2 , on utilise, dans la tres grande majorite 



1. Rappel sur l'heritage virtuel : e'est la classe situee le plus bas dans la hierarchie qui est 
responsable de 1' initialisation de toutes les classes de base virtuelles. 

2. Vous trouverez de nombreux articles consacres au principe de substitution de Liskov 
{Liskov Substitution Principle) sur le site www.objectmentor.com 
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des cas, I'heritage public. Neanmoins, et cela, la plupart des gens l'ignorent, on 
peut utiliser I'heritage non-public (prive ou protege) pour implementer un certain 
type de relation « EST-UN ». Considerons une classe Derivee , derivee de 
maniere privee de la classe Base. Bien evidemment, les instances de cette classe ne 
peuvent pas etre utilisees de maniere polymorphique par le biais d'un pointeur de 
type Base* depuis du code exterieur, car tous les membres de Derivee sont prives. 
Cependant, il est possible d'utiliser Derivee de maniere polymorphique depuis 
Vinterieur de Derivee elle-meme (c'est-a-dire depuis l'interieur des fonctions 
membres et amies de Derivee). En remplacant la derivation privee par une deriva- 
tion protegee, on etend la possibilite d'utiliser ce polymorphisme interne aux 
eventuelles classes derivees de Derivee, mettant ainsi en oeuvre un type particulier 
de relation « EST-UN » qui peut etre utile dans certains cas. 

Nous avons a present recense toutes les raisons pouvant justifier l'emploi de I'heri- 
tage prive ou protege. L' heritage public, quant a lui, n'est employe que pour modeliser 
une relation du type « EST-UN » (nous reviendrons sur ce point a 1' occasion de la der- 
niere question du probleme). 

A la lumiere des points precedents, nous pouvons maintenant repondre a la troi- 
sieme question : « Quelle est la meilleure version : MaListei ou MaListe2 ? » 

Prenons l'exemple de code n° 1 et voyons s'il remplit un ou plusieurs des criteres 
requis pour l'emploi de I'heritage prive ou protege : 

■ Necessite d'acceder aux membres proteges de la classe utilisee : non (Liste n'a 
pas de membres proteges) 

■ Necessite de redefinir des fonctions virtuelles : non (Liste n'a pas de fonctions 
virtuelles). 

■ Necessite de construire l'objet utilise avant l'objet utilisateur (et/ou de le detruire 
apres) : non (la classe MaListei n'a pas d' autre classe de base, il n'y a done pas 
de problemes lies aux durees de vie relatives de l'objet Liste et d'un objet de base 

de MaListei). 

■ Necessite de partager une classe de base virtuelle ou de redefinir le constructeur 
d'une classe de base virtuelle : non (la classe Liste n'a pas de classe de base vir- 
tuelle). 

■ Necessite d'optimiser les performances par emploi d'une « classe de base vide » : 
non (la classe Liste n'est pas vide). 

■ Necessite de mise en oeuvre du « polymorphisme partiel » : non (la classe 
MaListe n'est aucunement liee a la classe Liste par une relation de type EST-UN, 
meme depuis l'interieur des fonctions membres et amies de MaListe). Ce dernier 
point merite qu'on s'y attarde un instant car il met en evidence un des 
inconvenients (mineurs) de I'heritage : au cas ou un des criteres ci-dessus aurait 
ete rempli et que done la derivation de MaListe depuis Liste aurait ete justifiee et 
utilisee, cela aurait fait apparaitre le danger de 1' utilisation polymorphique acci- 
dentelle d'objets MaListe considered comme des objets Liste a partir des fonc- 
tions membres et amies de MaListe; possibilite certes rare mais potentielle source 
de confusion pour le developpeur inexperimente. 
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En resume, la meilleure solution est celle employant la composition (MaListe2). 
Utiliser l'heritage sans avoir une bonne raison de le faire introduit des couplages inuti- 
les et des dependances couteuses entre classes. Malheureusement, de trop nombreux 
developpeurs, meme parmi les plus experimentes, ont souvent recours a l'heritage 
alors que la composition suffit. 

Toutefois, le lecteur attentif aura peut etre note un avantage mineur (et sans grand 
interet) de la solution employant l'heritage sur celle employant la composition : dans 
le premier cas, il suffit d'ecrire une instruction « using » pour avoir acces a la fonc- 
tion size o ; dans le second cas, il faut implementer explicitement une nouvelle fonc- 
tion relayant l'appel a la fonction size () de l'objet contenu. 

Voyons maintenant un cas ou il est necessaire d' utiliser l'heritage : 

// Exemple 2 : Cas ou 1' utilisation d'heritage est justifiee 
// 

class Base 
{ 

public : 

virtual int Fonctionl (); 
protected : 

bool Fonction2 () ; 
private : 

bool Fonction3(); // fait appel a Fonctionl 

}; 

Dans cet exemple, nous considerons une classe Base dotee d'une fonction virtuelle 
Fonctionl o et d'une fonction protegee Fonction2 o. Le seul moyen de redefinir 
cette fonction virtuelle ou d' avoir acces a cette fonction protegee est de deriver une 
classe de Base. Notons au passage qu'il s'agit ici d'un exemple ou la redefinition 
d'une fonction virtuelle n'est pas effectuee uniquement a des fins de polymorphisme 
mais egalement pour modifier le comportement de la classe de base (la fonction 
Fonction3 ( ) faisant appel a Fonctionl ( ) dans son implementation). 

L'utilisation de l'heritage est done justifiee. Ceci etant, quelle est la meilleure 
maniere de mettre en ceuvre cet heritage ? Commentez 1' exemple suivant : 

// Exemple 2 (a) 

// 

class Derivee : private Base // necessaire ? 
{ 

public : 

int Fonctionl () ; 

// ... suivent plusieurs fonctions, dont 

// certaines font appel a Base : : Fonction2 ( ) 

// et d'autres non. 

}; 

Ce code permet la redefinition de Fonctionl o, ce qui est une bonne chose. En 
revanche, il donne acces a la fonction Base : :Fonction2 o a tons les membres de 
Derivee. Par consequent, il rend tous les membres de Derivee dependants de l'inter- 
face protegee de Base, ce qui est regrettable. 
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L'exemple 2(a) presente done 1' inconvenient d'introduire un couplage trop fort 
entre Derivee et Base. Neanmoins, il y a un moyen plus judicieux de realiser cette 
derivation : 

// Exemple 2 (b) 

// 

class Deriveelmpl : private Base 
{ 

public : 

int Fonctionl () ; 

// ... Suivent des fonctions utilisant Base : : Fonction2 ( ) 

}; 

class Derivee 
{ 

// ... Suivent des fonctions n'utilisant pas Base : : Fonction2 ( ) 
private : 

Deriveelmpl impl_; 

}; 

Cette deuxieme solution est bien meilleure car elle encapsule dans deux classes 
differentes les deux types de dependances etablies avec la classe Base : Derivee 
depend uniquement de l'interface publique de Base et ne depend plus de son interface 
protegee. Alors que dans l'exemple 2(a), la classe Derivee jouait deux roles (speciali- 
ser Base tout en faisant appel a elle), l'exemple 2(b) separe bien les roles, se 
conformant ainsi a la regie d'or de la conception objet : « une classe, une 
responsabilite ». 

Voyons maintenant quelques avantages apportes par 1' utilisation de la composi- 
tion : 

D'une part, la composition permet de disposer de plusieurs instances de la classe 
« utilisee », ce qui est difficile, voire parfois impossible a realiser avec l'emploi de 
I'heritage. Si vous avez besoin a la fois d'utiliser une relation d'heritage et d' avoir 
plusieurs instances, il faut utiliser une technique similaire a celle decrite dans l'exem- 
ple 2(b) : creez une classe utilitaire derivee (comme Deriveelmpl) puis agregez, dans 
la classe utilisatrice, plusieurs instances de cette classe utilitaire. 

D'autre part, l'utilisation de la composition apporte davantage de flexibilite : 

■ La classe de l'objet membre « utilise » peut etre facilement masquee derriere un 
pare-feu logiciel par la technique du « Pimpl 1 », alors que la definition d'une 
classe de base sera toujours visible. 

■ L'objet membre peut egalement etre facilement remplace par un pointeur, ce qui 
permet de changer facilement la nature de l'objet utilise a l'execution, ce qui n'est 
evidemment pas possible lorsqu'on utilise une classe de base. 

■ Utilisee conjointement avec des modeles de classes, la composition permet 
d'atteindre un tres bon niveau de genericite. 



1 . Voir les problemes 26 a 30 
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Pour illustrer ce troisieme point, voyons une version legerement modifiee de notre 
exemple 1 : 

// Exemple 1(c) : Composition generique 
// 

template <class T, class Impl = Liste<T> > 

class MaListe3 

{ 

public : 

bool Add ( const T& ); // appelle impl_. Insert ( ) 
T Get ( size_t index ) const; 

// appelle impl_. Access ( ) 
size_t SizeO const; // appelle impl_. Size ( ) ; 
// . . . 
private : 

Impl impl_; 

}; 

Au lieu d'avoir une classe MaListe « IMPLEMENTEE-EN-FONCTION-DE » 
Liste, nous avons a present une classe « IMPLEMENTABLE-EN-FONCTION-DE » 
n'importe quelle classe dont l'interface publique contient les fonctions Add o , Get o 
et size ( ) . C'est d'ailleurs une technique utilisee par la bibliotheque standard dans son 
implementation des modeles stack et queue, qui sont par defaut « IMPLEMENTES- 
EN-FONCTION-DE » dequeue, mais sont egalement « IMPLEMENTABLE-EN- 
FONCTION-DE » toute classe comportant la meme interface que dequeue. 

En pratique, cette genericite est utile car elle permet de specialiser le comporte- 
ment de la classe « utilisee ». Par exemple, pour un programme amene a effectuer un 
tres grand nombre d'insertions, on instanciera le modele de classe MaListe3 en pas- 
sant, en deuxieme parametre, une classe avec une fonction insert o specialement 
optimisee. L utilisation d'une valeur par defaut pour ce parametre assure une compati- 
bilite ascendante (MaListe3<int> etant synonyme de MaListe3<int, Liste<int>>). 

Ce niveau de flexibilite est difficile a atteindre avec 1' heritage, avec lequel les deci- 
sions d' implementation sont figees au moment de la conception d'une classe plutot 
que lors de son utilisation. Par exemple, faire deriver MaListe3 de Liste<T> aurait 
introduit un couplage supplementaire inutile. 

Pour finir, penchons-nous sur la derniere question de notre probleme : « En se 
replacant dans un contexte general, etablissez la liste des cas lesquels vous utiliseriez 
l'heritage public. » 

Concernant l'heritage public, il y a une regie simple mais fondamentale qu'il faut 
avoir en permanence a l'esprit : V unique cas justifiant l'emploi de l'heritage public est 
la mise en oeuvre d'une relation de type « EST-UN » au sens du principe de substitu- 
tion de Liskov 1 . Ce principe enonce que dans le contexte d'un code client utilisant un 
objet de la classe de base, la substitution d'un objet derive en lieu et en place de 
l'objet de base doit etre sans effet sur le comportement du code client [Remarque : 



1. Vous trouverez de nombreux articles consacres au principe de substitution de Liskov 
(Liskov Substitution Principle) sur le site www.objectmentor.com 
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nous abordons une des rares exceptions a cette regie - ou plus etre plus precis une 
extension - dans le probleme n° 3]. 

Prenez soin notamment d'eviter deux erreurs courantes : 

■ Ne jamais utiliser I'heritage public lorsque I'heritage prive ou protege est suf- 
fisant. L' heritage public ne doit jamais etre utilise pour traduire une relation du 
type « EST-IMPLEMENTE-EN-FONCTION-DE » en 1' absence de relation 
« EST-UN ». De trop nombreux developpeurs ne respectent malheureusement pas 
cette regie, pourtant fondamentale. II est inutile et couteux d' utiliser une relation 
d'heritage public lorsque I'heritage non-public fait l'affaire. Encore une fois, 
lorsqu'il y a plusieurs manieres d'implementer une relation entre classes, il faut 
systematiquement choisir celle qui cree la dependance la plus faible. 

■ Ne jamais utiliser I'heritage public pour implementer une relation du type 
« EST-PRESQU'UN ». Lorsqu'on met en oeuvre une relation d'heritage public 
entre deux classes, il faut s'assurer que toutes les fonctions virtuelles redefinies 
dans la classe derivee se comportent de maniere similaire aux fonctions correspon- 
dantes de la classe de base. Certains developpeurs, meme parmi les experimented, 
n'assurent parfois cette similarite de comportement que pour la plupart des fonc- 
tions virtuelles redefinies, ce qui presente une consequence tres genante : un code 
client initialement concu pour utiliser des objets de classes de base pourra ne pas 
avoir le meme comportement avec des objets derives de cette classe. Un exemple 
souvent cite (Robert Martin) est celui du carre et du rectangle : il faudrait soi- 
disant deriver « Carre » de « Rectangle » car « un carre est un rectangle 
particulier ». C'est vrai en mathematique, ca ne Test pas pour des classes. En effet, 
admettons que la classe Rectangle contienne une fonction virtuelle setLar- 
geur(int) et que cette fonction soit redefinie dans la classe Carre. A priori, 
1' implementation dans setLargeur (int) dans Carre mettra a jour a la fois la lar- 
geur et la hauteur avec la valeur passee en parametre, afin d' assurer que le carre 
conserve sa nature « carree ». Des lors, un probleme risque de se poser si du code 
client utilise un objet Rectangle de maniere polymorphique : en effet, ce code ne 
s'attendra pas a ce que la hauteur soit modifiee lorsqu'il fixe la largeur, ce qui est 
pourtant ce qui se passera ! Ceci est un bon exemple de mauvaise utilisation de 
I'heritage public. Les classes car re et Rectangle ne respectent pas le Principe de 
Substitution de Liskov car la classe derivee ne se comporte pas de la meme 
maniere que la classe de base. 

Lorsque je rencontre ce type de relation « EST-PRESQU'UN », j'attire systemati- 
quement 1' attention du developpeur sur les risques que ce type d' implementation pre- 
sente, en insistant en particulier sur le fait que l'utilisation polymorphique d'objets 
derives est susceptible de produire un resultat inattendu. Je m'entends frequemment 
repondre que ce n'est pas grave, qu'il s'agit la d'une incompatibilite mineure et que le 
risque qu'un code client provoque un probleme est faible. C'est generalement vrai 
lorsque le redacteur du code client est au courant des emplois a eviter. Mais, des 
annees plus tard, un developpeur realisant une operation de maintenance peut, en 
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apportant des modifications -meme mineures- a ce code, faire resurgir le probleme et 
passer des heures, voire des jours, a le reperer et a le corriger. 

Done, soyez fermes : une classe derivee qui ne se comporte pas comme une classe 
de base n' « EST PAS » une classe de base. Evitez done systematiquement d'utiliser 
1' heritage public dans ce cas-la. 



Recommandations 

N'utilisez I'heritage public que dans les cas ou la relation entre classe derivee et classe de 
base est de type « EST-UN » ou « FONCTIONNE-COMME-UN », au sens du Principe de Substi- 
tution de Liskov. 

N'utilisez pas I'heritage public pour reutiliser le code de la classe de base; utilisez I'heritage 
public pour etre reutilise par des objets externes utilisant le polymorphisme de la classe de base. 



Conclusion 

N'abusez pas de I'heritage. Pour modeliser une relation du type « EST-IMPLE- 
MENTE-EN-FONCTION-DE », preferez systematiquement l'emploi de la composi- 
tion, lorsque cela suffit. N' employ ez I'heritage public que pour modeliser une relation 
du type « EST-UN ». Evitez I'heritage multiple lorsque I'heritage simple suffit. Gar- 
dez a F esprit que les lourdes hierarchies de classe sont difficiles a comprendre et a 
maintenir, que I'heritage oblige a fixer des choix des la conception, ce qui reduit en 
consequence la flexibilite a 1' execution. 

Contrairement a une opinion communement repandue, il est tout a possible de 
programmer « Oriente-Objet » sans utiliser systematiquement I'heritage. Lorsque plu- 
sieurs solutions sont possibles, utilisez toujours la plus simple. Votre code n'en sera 
que plus stable et plus facile a maintenir. 



Pb n° 25. Procrammation orientee objet Difficulte : 4 



Abandonnons pour quelques instants les exemples de code pour nous poser une question plus 
generale, a laquelle il est souvent repondu trop categoriquement par I'affirmative : « Le C++ est- 
il un langage oriente-objet ? ». 



Discutez la phrase suivante : 

« Le C++ est un langage puissant presentant de nombreuses fonctionnalites orien- 
tees objet, notamment 1' encapsulation, la gestion des exceptions, I'heritage, les mode- 
les, le polymorphisme, le typage fort des donnees et la gestion des modules de code. » 
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Solution 



Le but de ce probleme etait d'amener le lecteur a reflechir sur les reelles possibili- 
tes du langage C++ : ses avantages mais egalement ses eventuelles insuffisances. 
Cette vaste question meriterait d'etre debattue longuement. Neanmoins, trois points 
principaux peuvent etre notes : 

1. II n'existe pas de definition precise du concept « oriente objet ». Bien que ce 
concept existe maintenant depuis de nombreuses annees, personne ne s'entend sur sa 
signification precise. Interrogez dix personnes et vous obtiendrez dix reponses differen- 
tes. Pratiquement une grande majorite s'accordera a dire que la programmation orientee 
objet s'articule autour des concepts d'heritage et de polymorphisme; la plupart incluront 
egalement 1' encapsulation; d'autres citeront peut-etre la gestion des exceptions; certains, 
plus rares, ajouteront la notion de modele {template); chacun saura defendre son point 
de vue avec force arguments, prouvant ainsi qu'il n'y a pas de definition unique de 
1' « Oriente-Objet » 

2. Le langage C++ est un langage multi-facettes. C++ n'est pas uniquement un lan- 
gage oriente objet. Bien qu'il presente un grand nombre de fonctionnalites orientees 
objet, il n'impose pas leur utilisation. II est tout a fait possible d'ecrire des program- 
mes non oriente objet en C++; de nombreux developpeurs le font. 

Tous les efforts de normalisation du langage ont converge vers un but commun : 
doter le C++ de fortes capacites d' abstraction, lui permettant de reduire au maximum 
la complexite des logiciels (MartinQS) 1 . C++ n'est pas limite a la programmation 
orientee objet : il autorise plusieurs styles de programmations. Parmi ces styles, les 
plus importants sont la programmation orientee objet et la programmation generique, 
qui, par leurs capacites d' abstraction, permettent la realisation de programmes modu- 
laires. La programmation orientee objet, en permettant le regroupement des variables 
d'etat caracterisant une entite et des fonctions les manipulant, ainsi que 1' encapsula- 
tion et 1' heritage, permet d'ecrire du code plus clair, plus modulaire et plus facile a 
reutiliser. La programmation generique, plus recente, permet d'ecrire des fonctions et 
de classes manipulant des objets dont le type est inconnu a l'avance, offrant ainsi un 
moyen de diminuer drastiquement le couplage entre les differents elements d'un pro- 
gramme. Peu de langages, a l'heure actuelle, sont aussi complets en matiere de pro- 
grammation generique. Les modeles {templates) C++ sont d'ailleurs a Forigine de la 
programmation generique moderne. 

En conclusion, le langage C++ offre aujourd'hui, grace au travail realise par les 
comites de normalisation, deux techniques majeures : programmation orientee objet et 
programmation generique. Leur combinaison permet d' atteindre un niveau d' abstrac- 
tion et de flexibilite inegale. 



1. Cet excellent ouvrage demontre en quoi l'un des avantages principaux de la POO est la 
possibilite de reduire la complexite des logiciels en gerant finement les dependances au 
sein du code. 
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3. Aucun langage n'est parfait. Si C++ est le langage qui vous utilisez le plus 
aujourd'hui, qui peut predire si vous ne trouvez pas mieux demain ? C++ n'est pas 
parfait : il ne permet pas la gestion fine des modules, n' a pas de « ramasse-miettes » 
memoire, implemente un typage statique des donnees mais pas veritablement de 
typage « fort ». Tout langage a ses avantages et ses inconvenients. Ne soyez pas irre- 
mediablement inconditionnel d'un unique langage: sachez choisir, en fonction des 
circonstances le langage le mieux adapte a vos besoins. 
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La robustesse d'un programme est souvent tres liee a la maniere dont sont gerees 
les dependances au sein du code. Le langage C++ dispose de deux puissantes metho- 
des d' abstraction, la programmation orientee objet et la programmation generique 
(Sutter98). Les fonctionnalites qu'elles offrent - encapsulation, polymorphisme, 
genericite - sont autant d'outils utilisables pour reduire les dependances entre modu- 
les et, par consequent, minimiser la complexite des programmes. 



PB N° 26. EVITER LES COMPILATIONS INUTILES 

(1 re partie) Difficulte : 4 



La gestion des dependances ne concerne pas uniquement ce qui se passe a I'execution du pro- 
gramme - comme les interactions entre classes - mais egalement la phase de compilation, sur 
laquelle nous nous concentrerons dans ce probleme. Nous nous interesserons dans cette pre- 
miere partie a I'elimination des fichiers en-tete inutiles. 



De nombreux developpeurs ont la mauvaise habitude d'inclure souvent plus de 
fichiers en-tete que necessaire. Ceci peut alourdir considerablement les temps de com- 
pilation, notamment lorsqu'un fichier en-tete en inclut de nombreux autres. 

Examinez le code ci-dessous. Identifiez et supprimez - ou remplacez - les instruc- 
tions #inciude superflues, sans que cela necessite de modifier le reste du code. Les 
commentaires sont importants. 

// x.h: Fichier original 

// 

finclude <iostream> 
#include <ostream> 
tinclude <list> 
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// Les classes A, B, C, D et E ne sont pas 
// des modeles de classe. 

// A et C comportent des fonctions virtuelles. 

#include "a.h" // classe A 

#include "b.h" // classe B 

#include "c.h" // classe C 

#include "d.h" // classe D 

#include "e.h" // classe E 

class X : public A, private B 
{ 

public : 

X ( const C& ) ; 
B f ( int, char* ) ; 
C f ( int, C ) ; 
C& g ( B ) ; 
E h ( E ) ; 

virtual std: : ostreamS print ( std :: ostreamS ) const; 
private : 

std::list<C> clist_; 
D d_; 

}; 

inline std :: ostreamS operator<< ( std: : ostreamS os, const Xs x ) 
{ 

return x . print ( os ) ; 

} 




Le premier fichier en-tete peut etre purement et simplement supprime, tandis que 
le second peut etre remplace par un autre fichier plus leger. 

1. Supprimer <iostream> 

#include <iostream> 

Beaucoup de developpeurs ont la mauvaise habitude d'inclure systematiquement 
<iostream>, des que leur code fait appel a quelque chose ressemblant de pres ou de 
loin a un flux. Dans notre exemple, la classe x ne fait appel qu'a ostream et done 
l'inclusion de <ostream> est suffisante, bien qu' encore legerement superflue comme 
nous allons le voir immediatement. 



Recommandation 

Ne jamais inclure de fichiers en-tete inutiles. 



2. Remplacer <ostream> par <iosfwd> 
#include <ostream> 
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Dans notre exemple, il n'est pas necessaire de definir le type du parametre et de la 
valeur de retour de la fonction print pour que la compilation de x . h s'effectue correc- 
tement : la declaration « en avance » d'ostream suffit. 

On peut done s'affranchir de « tinciude <iostream> ». En revanche, on ne peut 
pas le remplacer par une declaration de type « class ostream ; »: cette syntaxe fut 
possible a une epoque, mais ne Test plus aujourd'hui pour les deux raisons suivantes : 

■ ostream est maintenant contenue dans l'espace de nommage std, a l'interieur 
duquel les developpeurs ne sont pas autorises a declarer des classes. 

■ En realite, ostream n'est pas une classe mais une definition de type (typedef) : 
basic_ostream<char> . Par consequent, avant de declarer ostream, il faudrait 
egalement declarer basic_ostream<>, ce qui pourrait poser probleme car les 
implementations de la bibliotheque standard utilisent souvent des parametres sup- 
plementaires a usage interne pour les modeles de classes - e'est d'ailleurs la prin- 
cipale raison de 1' interdiction faite aux developpeurs d'effectuer des declarations 
au sein de std. 

Heureusement, nous pouvons utiliser le fichier en-tete standard <iosfwd>, qui 
contient les declarations en avance de tous les modeles de classe relatifs aux flux (dont 

basic_ostream) ainsi que leur typedef associe (dont ostream). 

En conclusion, nous pouvons remplacer « # in dude <iostream> » par 
« #include <iosfwd> ». 



Recommandation 

Lorsqu'une declaration « en avance » suffit, utilisez <iosfwd> plutot que les autres fichiers 
en-tete relatifs aux flux. 



II faut noter qu'il n'existe pas d'equivalent de <iosfwd> dans les autres modeles 
de classe de la bibliotheque standard (on aurait pu imaginer <iistfwd> pour list ou 
<stringfwd> pour string...). En effet, le cas d'<iosfwd> est specifique puisqu'il a 
ete cree pour faciliter la compatibilite ascendante lors de 1' introduction de la version 
d'<iostream> basee sur des modeles de classe. 

Arrive a ce point, le lecteur averti aurait pu s'etonner du fait que le fichier x . h ne 
se contente pas de faire reference a ostream en tant que parametre d'entree ou valeur 
retournee mais utilise bel et bien le type ostream (dans l'operateur <<) et que, par 
consequent, une definition de ce type s'impose. 

Ceci aurait ete une remarque sensee, mais neanmoins inexacte. En effet, 
considerons a nouveau la fonction en question : 

inline std: : ostreamS operator<< ( std : : ostreamS os, const X& x ) 
{ 

return x. print (os); 

} 

Cette fonction utilise ostreams en parametre d'entree et valeur de retour (ce qui, 
comme la majorite des developpeurs le savent, ne requiert pas la definition de 
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ostream). Dans son implementation, la fonction passe a son tour le parametre recu a 
une autre fonction ce qui, et cela beaucoup moins de gens le savent, ne requiert pas 
non plus de definition. 

Comme ce sont la les seules operations effectuees avec ostream, il n'est pas 
necessaire d'en inclure la definition. Bien entendu, si la fonction operator<< avait fait 
appel a une fonction membre de os, nous aurions eu besoin de la definition. 

3. Remplacer « e . h » par une declaration « en avance » 

#include « e.h » // classe E 

Le code ne fait reference a la classe E que comme parametre d' entree ou valeur de 
retour, par consequent la definition complete de E n'est pas necessaire et nous pou- 

VOnS remplacer « #include « e.h » » par « class E ; » 



Recommandation 

Ne jamais inclure un fichier en-tete lorsqu'une declaration « en avance » suffit. 



pb n° 27. eviter les compilations inutiles (2 e par 

tie) Difficulte : 6 



Les fichiers en-tete superflus etant elimines, passons maintenant a I'etape suivante : rendre le 
code le moins dependant possible des parties privees des classes. 

Repartons de l'exemple du fichier precedent, a present affranchi de quelques 
fichiers en-tete inutiles. Identifier les fichiers en-tete supplementaires dont on peut se 
passer, a condition d'effectuer quelques modifications a la classe x. Attention : vous 
ne pouvez pas modifier la liste des classes dont herite X ni la partie publique de X; les 
modifications effectuees ne doivent pas avoir d' impact sur le code client utilisant X - 
si ce n'est une recompilation. 

// x.h: Apres suppression des en-tetes inutiles 
// 

tinclude <iosfwd> 
finclude <list> 



// Les classes A, B, C, D et E ne sont pas 
// des modeles de classe. 

// A et C comportent des fonctions virtuelles. 



#include 
#include 
#include 
(finclude 



"a.h" // 

"b.h" // 

"e.h" // 

"d.h" // 



classe A 
classe B 
classe C 
classe D 
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tinclude "e.h" // classe E 
cldss E ; 

class X : public A, private B 
{ 

public : 

X ( const C& ) ; 
B f ( int, char* ) ; 
C f ( int, C ) ; 
C& g ( B ) ; 
E h( E ) ; 

virtual std : : ostreams print ( std: : ostreams ) const; 
private : 

std::list<C> clist_; 
D d_; 

}; 

inline std: : ostreamS operator<< ( std : : ostreamS os, const X& x ) 
{ 

return x. print (os); 

} 



)- Solution 



Examinons les fichiers en-tete que nous n'avions pas pu supprimer lors du pro- 
bleme precedent : 

■ « a . h » et « b . h » contiennent les definitions des classes a et b - qui sont des clas- 
ses de base de x. Nous n'avions pas pu les supprimer car le compilateur en a 
besoin pour determiner, en particulier, la taille des objets X et les fonctions virtuel- 
les. Nous ne pourrons pas non plus les supprimer dans ce probleme, au vu des 
contraintes imposees par Fenonce. Neanmoins, nous verrons comment il est possi- 
ble (et pourquoi il est opportun) de le faire a l'occasion du probleme suivant. 

■ « c . h » contient la definition de la classe c, qui est utilisee pour instancier le 
modele de classe iist<c>. Dans leur grande majorite, les compilateurs imposent 
le fait que la definition de t soit visible lorsque Ton instancie un modele de classe 
iist<T> (bien qu'elle ne soit pas imposee par la norme C++, cette contrainte 
devient tellement repandue qu'elle finira pas etre normalisee), pourtant nous allons 
trouver un moyen de supprimer « #inciude c . h » 

■ « d . h » contient la definition de la classe d, dont le type est utilise pour une varia- 
ble membre privee de x. Nous allons egalement nous passer de « #inciude d.h » 

Nous allons maintenant utiliser une technique particuliere qui va nous permettre 
de supprimer les fichiers en-tete « c . h » et « d . h » : la technique du « Pimpl ». 

Le langage C++ permet facilement de controler Faeces a certains membres d'une 
classe, a travers la notion de partie privee. En revanche, il est beaucoup moins facile 
de rendre un code client d'une classe independant de la partie privee de cette classe. 
Dans F ideal, Fencapsulation devrait permettre de decoupler totalement le code client 
et les details d' implementation d'une classe. Par le mecanisme des variables privees, 
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le C++ rend possible en partie de cette encapsulation; neanmoins le fait que la partie 
privee d'une classe soit declaree dans le fichier en-tete de cette classe - heritage du C 
- rend le code client dependant des types utilises dans cette partie privee. 

Un des meilleurs moyens pour encapsuler totalement la partie privee d'une classe 
est Futilisation d'un pare-feu logiciel (Coplien92, Lakos96, Meyers98, Meyers99, 
Murray93) ou « Pimpl » (ainsi nomme en raison de l'utilisation d'un pointeur 

pimpl_'). 

Un Pimpl est un pointeur membre particulier utilise pour masquer la partie privee 
d'une classe. II pointe vers une structure definie dans 1' implementation de la classe. 
Autrement dit, au lieu d'ecrire : 

// Fichier x.h 

class X 

{ 

// Membres publics et proteges 
private : 

// Membres prives. S'ils changent, 

// tout le code client doit etre recompile 



on ecnra : 



// Fichier x.h 



class X 
{ 

// Membres publics et proteges 
private : 

struct Xlmpl* pimpl_; 

// Pointeur vers une structure qui sera definie plus tard 

}; 



// Fichier x . cpp 
struct X::XImpl 
{ 

// contient les membres prives. Desorraais, 
// il est possible de le changer sans avoir 
// a recompiler le code client 

}; 



Chaque objet x alloue dynamiquement un objet interne ximpi. D'une certaine 
maniere, nous avons deplace la partie privee de l'objet pour la cacher derriere un poin- 
teur opaque, le « Pimpl ». 

L' avantage principal de cette technique est de reduire les dependances au sein du 
code et done de minimiser les risques de recompilation : 



1. Comme nous allons le voir, le terme « Pimpl » fait reference a l'utilisation d'un poin- 
teur membre (d'ou p) vers une structure privee contenant les details de l'i'mp/ementa- 
tion, d'ou « pimpl ». 
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■ Les types utilises dans 1' implementation de la classe n'ont pas besoin d'etre vus 
depuis le code client, ce qui permet de reduire le nombre de fichiers en-tete inclus 
et done les temps de compilation. 

■ L' implementation d'une classe peut etre modifiee sans que le code client ait besoin 
d'etre recompile. 

En revanche, cette technique degrade un peu les performances : 

■ Chaque construction / destruction s'accompagne d'une allocation / deallocation 

■ Chaque acces a un membre prive necessite au moins une indirection supplemen- 
taire (si le membre prive auquel on accede appelle lui-meme une fonction dans la 
partie visible de la classe, cela necessitera plusieurs indirections) 

En appliquant cette technique a notre exemple de code, nous pouvons eliminer 
trois fichiers en-tete qui n'etaient utilises que par la partie privee de X : 

#include <list> 

#include « c.h » // classe C 

#include « d.h » // classe D 

Le fichier « c.h » doit etre remplace par une declaration « class c; » car le type 
c est utilise comme parametre et type de retour dans la partie publique de la classe. En 
revanche, les deux autres fichiers peuvent disparaitre completement. 



P3 



Recommandation 



Lorsque vous implementez une classe destinee a etre largement utilisee, utilisez la techni- 
que du pare-feu logiciel (ou technique du « Pimpl ») afin de masquer la partie privee de la 
classe. Pour cela, declarez un pointeur membre « struct xxxximpi* pimpi_ », vers une struc- 
ture qui sera definie dans I'implementation de la classe et contiendra les variables et fonctions 

membres phves. Par exemple :« class Map { private : struct Maplmpl* pimpl_; }; ». 



Voici a quoi ressemble le code apres modification : 



// x.h: Apres mise en place d'un "Pimpl" 

// 

finclude <iosfwd> 

finclude "a.h" // classe A (a des fonctions virtuelles) 
finclude "b.h" // classe B (n'a pas de fonctions virtuelles) 
class C ; 
class E ; 

class X : public A, private B 
{ 

public : 

X ( const C& ) ; 
B f( int, char* ); 
C f ( int, C ) ; 
C& g ( B ) ; 
E h ( E ) ; 

virtual std : : ostreams print ( std: : ostreams ) const; 
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private : 

struct Xlmpl* pimpl_; 

// Pointeur vers une structure definie dans 
// 1' implementation de la classe 

}; 

inline std :: ostreamS operator<< ( std: : ostreamS os, const X& x ) 
{ 

return x . print ( os ) ; 

} 

Le code client n'est plus dependant de la partie privee de x, qui se retrouve dans 
le fichier source « x . cpp » : 

// Fichier source : x . cpp 
// 

struct X::XImpl 
{ 

std::list<C> clist_; 
D d_; 

>; 

En conclusion, nous avons reussi a eliminer trois fichiers en-tete, ce qui n'est pas 
negligeable. Nous allons pouvoir faire encore mieux dans le probleme suivant, ou 
nous allons etre autorises a modifier plus largement encore la structure de x. 



pb n° 28. eviter les compilations inutiles (3 e par 

tie) Difficulte : 7 



Les fichiers en-tete inutiles ont ete supprimes, la partie privee de la classe a ete correctement 
encapsulee... est-il possible de decoupler encore plus fortement notre classe du reste du pro- 
gramme ? Reponse dans ce probleme, qui nous permettra de revenir sur quelques principes de 
base de la conception de classes. 



Repartons une nouvelle fois de l'exemple etudie dans les deux problemes prece- 
dents. Nous nous sommes a present affranchis d'un grand nombre de fichiers en-tete 
superflus. Est-il possible de supprimer encore d'autres directives « #inciude » ? Si 
oui, comment ? 

Vous pouvez apporter des modifications a la classe x, dans la mesure ou son inter- 
face publique est inchangee et ou le code client ne necessite aucun changement - a 
part une recompilation. Encore une fois, les commentaires sont importants. 

// x.h: Apres mise en place d'un "Pimpl" 

// 

#include <iosfwd> 

#include "a.h" // classe A (a des fonctions virtuelles) 
#include "b.h" // classe B (n'a pas de fonctions virtuelles) 
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class C ; 
class E ; 

class X : public A, private B 
{ 

public : 

X ( const C& ) ; 
B f( int, char* ); 
C f ( int, C ) ; 
C& g ( B ) ; 
E h ( E ) ; 

virtual std : : ostreamS print ( std: : ostreamS ) const; 
private : 

struct Xlmpl* pimpl_; 

// Pointeur vers une structure definie dans 

// 1' implementation de la classe 

}; 

inline std: : ostreamS operator<< ( std : : ostreamS os, const X& x ) 
{ 

return x . print (os ) ; 

} 




De trop nombreux developpeurs ont la mauvaise habitude d'utiliser 1' heritage plus 
souvent que necessaire. Comme nous avons pu le voir dans le probleme n° 24, la rela- 
tion d' heritage (qui signifie notamment « EST-UN ») est beaucoup plus forte qu'une 
relation du type « A-UN » ou « UTILISE-UN ». Pour minimiser les dependances au 
sein du code, preferez systematiquement la composition (utilisation d'un objet mem- 
bre) a 1' heritage, lorsque cela suffit. Pour paraphraser Albert Einstein : « Utilisez un 
couplage aussi fort que necessaire, mais pas plus fort. » 

Dans notre exemple, x derive de a de maniere publique et de b de maniere privee. 
Comme nous l'avons vu dans le chapitre precedent, 1' heritage public ne doit etre uti- 
lise que pour implementer une relation « EST-UN » et satisfaire au principe de substi- 
tution de Liskov l . 

La classe a comportant des fonctions virtuelles, on peut considerer que la relation 
entre x et a est de type « EST-UN » et que done 1' heritage public se justifie. En revan- 
che, b est une classe de base privee de x ne comportant pas de fonctions virtuelles. 
L'unique raison qui pourrait justifier Futilisation de 1' heritage prive plutot que la com- 
position serait le besoin pour x de redefinir des fonctions virtuelles ou d' acceder a des 
membres proteges de b 2 . Si on considere que ce n'est pas le cas de la classe x, alors il 



1. On peut trouver un certain nombre d' articles relatifs au LSP (Liskov Substitution Prin- 
cipe) sur le site www.objectmentor.com. Voir aussi Martin95. 

2. II peut exister d'autres situations necessitant une relation d'heritage, neanmoins elles 
sont tres peu nombreuses. Voir Sutter98(a) et Sutter99 pour un examen exhaustif des 
(rares) situations justifiant l'emploi de l'heritage. Ces articles exposent clairement les 
raisons pour lesquelles il faut en general preferer la composition a l'heritage. 
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est preferable de remplacer la relation d' heritage par une relation de composition, a 
savoir remplacer la classe de base b par un objet membre de type b. 

Cet objet membre pouvant etre place dans la partie privee de x (pimpi_), nous pou- 
vons supprimer un fichier en-tete supplementaire : 

#include "b.h" // classe B (n'a pas de fonctions virtuelles) 

En revanche, nous avons toujours besoin d'une declaration « en avance » de B, 
dont le type est mentionne dans la declaration d'une fonction membre. 



Recommandation 

Ne jamais utiliser I'heritage lorsque la composition suffit. 



Nous aboutissons pour finir a un code tres simplifie par rapport a l'original : 

// x.h: Apres elimination de la classe de base B 
// 

#include <iosfwd> 

#include "a.h" // class A 

class B; 
class C; 
class E; 

class X : public A 
{ 

public : 

X ( const C& ) ; 
B f ( int, char* ) ; 
C f ( int, C ) ; 
C& g ( B ) ; 
E h ( E ) ; 

virtual std: : ostreams print ( std : : ostreams ) const; 
private : 

struct Xlmpl* pimpl_; // contient un objet de type B 

}; 

inline std :: ostreams operator<< ( std: : ostreams os, const X& x ) 
{ 

return x . print (os ) ; 

} 

En trois passes progressives et sans modifier 1' interface publique de x, nous avons 
finalement reduit le nombreux de fichiers en-tete utilises de huit a deux ! 
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Difficulte : 6 



Utiliser la technique du « Pimpl » permet de reduire fortement les dependances au sein du code 
et, par consequent, les temps de compilation. Neanmoins, quelle est la meilleure facon d'utiliser 




Un des inconvenients du C++ est 1' obligation de recompiler tout le code utilisant 
une classe lorsque la partie privee de cette classe est modifiee. Pour eviter cela, on uti- 
lise couramment la technique du « Pimpl » qui consiste a masquer les details de 
1' implementation d'une classe derriere un pointeur membre : 

class X 
{ 

public : 

/* ... membres publics ... */ 
protected: 

/* ... membres proteges (?) ... */ 
private : 

/* ... membres prives (?) ... */ 
struct Xlmpl* pimpl_; 

// Pointeur vers une structure definie dans 

// 1' implementation de la classe 



1. Quels elements de x faut-il mettre dans ximpi ? 

■ Toutes les variables privees (mais pas les fonctions) de x 

■ Tous les membres prives (variables et fonctions) de x 

■ Tous les membres prives et proteges de x 

■ Tous les membres de x, y compris les membres publics (1' interface publique de x 
ne contenant plus que des fonctions de transfert vers les fonctions correspondantes 
implementees dans ximpi). 

Discutez les avantages et inconvenients de chacune de ces solutions. 

2. ximpi doit-il contenir un pointeur vers l'objet x ? 



)- Solution 



La classe X utilise une technique de masquage de 1' implementation initialement 
documented par Coplien (Coplien92), consistant a separer la partie visible d'une 
classe et son implementation (ximpi). Utilisee au depart pour gerer le partage d'une 
implementation entre plusieurs utilisateurs, cette technique est maintenant couram- 
ment utilisee pour reduire les dependances au sein d'un programme. Comme nous 
l'avons vu dans les problemes 28 et 29, utiliser la classe interne ximpi permet de 
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reduire les temps de compilation grace a 1' elimination d'un certain nombre de 
« #inciude » et de rendre le code client d'une classe totalement independant de la 
partie privee de cette classe (il est possible d'ajouter / supprimer des membres situes 
dans ximpi sans avoir a recompiler le code client). 

Prenons les questions dans l'ordre : 

1. Quels elements de x faut-il mettre dans ximpi ? 

Option 1 (Note : 6/10) : Toutes les variables privees (mais pas les fonctions) de x. 
Cette option permet rendre le code client de classe independant des types utilises dans 
la partie privee de x (dans le fichier en-tete de la classe, on peut remplacer les 
#inciude declarant ces types par des declarations « en avance »). En revanche, le 
code client est toujours dependant des modifications apportees aux fonctions privees. 

Option 2 (Note : 10/10) : Tous les membres prives (variables et fonctions) de x. 
Cette option permet de rendre le code client totalement independant de la partie privee 
de la classe X. C'est en general la meilleure solution, a deux details pres : 

■ Les fonctions virtuelles privees ne seront plus visibles depuis le code exterieur : 
par consequent, elles ne pourront plus etre appelees par un code client, ni redefi- 
nies dans une classe derivee. Bien entendu, il est rare que Ton definisse des fonc- 
tions virtuelles privees, mais cela peut arriver (elles ne seront alors appelables que 
par des fonctions ou des classes amies). 

■ II sera parfois necessaire d'inclure dans ximpi un pointeur vers l'objet externe 
(souvent appele seif_) afin de pouvoir faire appel aux membres non-prives, ce qui 
introduit un niveau d' indirection supplementaire pouvant degrader les performan- 
ces. Pour eviter cela, un bon compromis est d'inclure egalement dans ximpi ce 
type de membres (voir la reponse a la question 2, consacree a ce probleme). 



Recommandation 

Lorsque vous implementez une classe destinee a etre largement utilisee, utilisez la techni- 
que du pare-feu logiciel (ou technique du « Pimpl ») afin de masquer la partie privee de la 
classe. Pour cela, declarez un pointeur membre « struct xxxximpi* pimpi_ », vers une struc- 
ture qui sera definie dans I'implementation de la classe et contiendra les variables et fonctions 

membres prives. Par exemple :« class Map { private : struct Maplmpl* pimpl_; }; » 



Option 3 (Note : 0/10) : Tous les membres prives et proteges de x. Cette option 
est a eviter absolument : il ne faut jamais masquer les membres proteges d'une classe 
dans un « Pimpl », car cela rend impossible leur utilisation par les classes derivees, ce 
qui est pourtant leur finalite ! 

Option 4 (Note : 10/10 dans certaines situations) : Tous les membres de x, y compris 
les membres publics (1' interface publique de x ne contenant plus que des fonctions de 
transfert vers les fonctions correspondantes implementees dans ximpi). Cette option 
peut etre utile dans certains cas, dans la mesure ou elle permet de se passer de pointeur 
vers l'objet externe, toutes les fonctions de la classe etant accessibles directement depuis 
ximpi. Le revers de la medaille est que ce sont maintenant les fonctions publiques trans- 
ferant les appels vers ximpi qui subissent un niveau d'indirection supplementaire. 
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2. ximpi doit-il contenir un pointeur vers l'objet x ? 

Parfois, oui. Un pointeur vers l'objet externe est necessaire dans le cas ou une 
fonction privee - implementee dans ximpi - aurait besoin d'acceder a une fonction 
non-privee de la classe, ce qui peut tout a fait arriver. Pour eviter 1' utilisation d'un 
pointeur de ce type, qui introduit un niveau d' indirection supplementaire, on peut uti- 
liser une solution intermediate entre les options 2 et 4 : mettre dans ximpi tous les 
membres prives et les fonctions publiques et protegees appelees depuis les fonctions 
privees. 



Pb n° 29. La technique du « Pimpl Rapide » Difficulte : 6 



Reduction des dependances rime malheureusement souvent avec degradation des performan- 
ces. Dans ce probleme, nous etudions une technique particuliere de « Pimpl » efficace tant au 
niveau de la compilation que de I'execution. 



La technique du « Pimpl » telle que nous l'avons etudiee dans les problemes pre- 
cedents necessite l'allocation dynamique d'un objet membre contenant l'implementa- 
tion de la classe. Toute operation d' allocation dynamique (par new ou maiioc) etant 
relativement couteuse - notamment par rapport a un appel classique de fonction, ceci 
peut avoir un impact negatif sur la performance d'un programme : 

// Technique originale 

// 

// Fichier y.h 

class X ; 
class Y 
{ 

/*...*/ 

X* px_; 

}; 



// file y . cpp 

#include "x.h" 

Y: : Y () : px_ ( new X ) { } 

Y::~Y() { delete px_; px_ =0; } 

Une variante possible serait d'utiliser un veritable objet membre : 

// Variante n° 1 
// 

// Fichier y.h 
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#include "x.h" 

class Y 
{ 

/*...*/ 
X x_; 

}; 

// Fichier y . cpp 
Y::Y() {} 

Malheureusement, ceci rend le code client de y dependant de la declaration de x, 
ce qui annule tout le benefice apporte par le « Pimpl ». 

Voici une seconde variante, permettant d'eliminer a la fois la declaration de x et le 
recours a 1' allocation dynamique : 

// Variante n° 2 

// Fichier y.h 

class Y 
{ 

/*...*/ 

static const size_t sizeofx = /* une certaine valeur*/; 
char x_[sizeofx]; 

}; 

// Fichier y . cpp 

ffinclude "x.h" 

Y: :Y() 
{ 

assert ( sizeofx >= sizeof (X) ) ; 
new (&x_[0]) X; 

} 

Y : : ~Y ( ) 
{ 

(reinterpret_cast<X*> (&x_[0] ) ) ->~X () ; 

} 

1. Quelle est l'occupation memoire supplementaire induite par la « Technique du 
Pimpl » par rapport a une implementation classique ? 

2. En quoi la « Technique du Pimpl » degrade-t-elle les performances par rapport a 
une implementation classique ? 

3. Commentez la variante n° 2. Vous inspire-t-elle un moyen encore meilleur de 
s'affranchir de l'occupation memoire supplementaire et de la degradation de per- 
formance generees par l'utilisation d'un « Pimpl » ? 

Pour plus d' informations sur la technique du Pimpl, reportez-vous au probleme 
n°29. 
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Solution 



1 . Quelle est V occupation memoire supplemental induite par la technique du Pimpl 
par rapport a une implementation classique ? 

L'emploi d'un « Pimpl » induit une occupation memoire egale au minimum a la 
taille d'un pointeur, parfois deux lorsque l'objet interne contient un pointeur vers 
l'objet externe. Avec un compilateur utilisant des pointeurs sur 32 bits - le plus cou- 
rant actuellement, ceci represente theoriquement un espace memoire de 4 ou 8 octets. 
En pratique, ces 8 octets peuvent se transformer en 14 octets ou plus, en raison de 
contraintes d' alignements memoire. Pour mieux comprendre ce dernier point, 
considerez Fexemple suivant : 

struct X { char c; struct Xlmpl* pimpl_; } ; 
struct X::XImpl { char c; }; 
int main ( ) 
{ 

cout << sizeof (X :: Xlmpl ) << endl 



Avec la plupart des compilateurs classiques utilisant des pointeurs codes sur 32 
bits, ce code va produire le resultat suivant : 



Autrement dit, l'occupation memoire generee par l'emploi de pimpi_ est de 7 
octets (et non pas 4, comme on pourrait s'y attendre). Ce qui justifie ces trois octets 
supplementaires est le fait qu'en general, les compilateurs alignent les pointeurs sur 
des adresses multiples de 4 (pour des raisons d' optimisation). La structure x compor- 
tant un premier membre type char (1 octet), le compilateur introduit 3 octets supple- 
mentaires vides avant le pointeur pimpi_, qui represente done globalement un « cout » 
de 7 octets. Si la structure ximpi contient elle-meme un pointeur vers l'objet externe, 
ce cout peut s'elever jusqu'a 14 octets dans le cas d'une machine 32 bits et 30 octets 
pour une machine 64 bits. 

II n'est en general pas possible de s'affranchir de ces octets supplementaires, sinon 
au prix de manoeuvres dangereuses et peu recommandables que je detaillerai plus loin, 
dans le paragraphe separe « Les dangers de 1' optimisation a tout va ». 

Dans les cas tres specifiques ou la minimisation de la taille memoire a vraiment 
une importance cruciale pour votre programme, un moyen - malheureusement non 
portable - de supprimer en partie ces octets vides est le recours aux directives 
#pragma du compilateur permettant de redefinir l'alignement par defaut pour une 
classe donnee. Ainsi, dans le cas ou votre compilateur autoriserait le controle de l'ali- 
gnement par l'utilisateur, vous pouvez gagner jusqu'a 6 octets par objet X - au prix 
d'une degradation (minuscule) des performances due au fait que le pointeur ne sera 
plus optimise. Autant dire que le gain d'espace memoire est ridiculement faible (sauf 
dans le cas d'un nombre enorme d'instances) eu egard au fait que le code a ete rendu 



<< sizeof (X) << endl; 



1 

8 



© copyright Editions Eyrolles 



120 Pare-feu logiciels 



non portable. D'une maniere generate, il est sage d'eviter d'optimiser plus que nature 
un programme au detriment de sa lisibilite ou de sa portabilite. 

2. En quoi la technique du Pimpl degrade-t-elle les performances par rapport a une 
implementation classique ? 

La technique du Pimpl est penalisante a deux niveaux : 

■ D'une part, chaque construction/destruction d'un objet x s'accompagne d'une 
allocation/desallocation d'un objet ximpi - ce qui est une operation couteuse 1 . 

■ D' autre part, chaque acces a un membre de ximpi depuis un membre de la classe 
x passe au minimum par un niveau d' indirection (plusieurs niveaux dans le cas ou 
ximpi contiendrait un pointeur vers l'objet externe qu'elle utilise pour appeler 
elle-meme des fonctions dans la classe x). 

Pour diminuer le cout en performance, il est possible d'utiliser la technique du 
« Pimpl Rapide » que nous allons etudier maintenant. 

3. Commentez la variante n° 2 . Vous inspire-t-elle un moyen encore meilleur de 
s'affranchir de V occupation memoire supplementaire et de la degradation de per- 
formance generees par V utilisation d'un « Pimpl » ? 

Cette variante n° 2 est incorrecte et dangereuse ! Ne l'utilisez PAS ! Elle presente 
un grand nombre de problemes et risques qui seront decrits dans le paragraphe « Les 
dangers de 1' optimisation a tout va » situe a la fin de ce chapitre. 

Neanmoins, l'idee sous-jacente de cette variante consistant a utiliser une zone 
memoire « pre-allouee » pour reduire le cout en performance induit par des alloca- 
tions dynamiques repetees est tout a fait interessante. Nous allons voir maintenant 
comment mettre en oeuvre correctement ce type de mecanisme en utilisant la techni- 
que dite du « Pimpl Rapide », qui consiste a redefinir pour la structure ximpi, un ope- 
rateur new { ) specifique utilisant des blocs pre-alloues : 

// Fichier x.h 

class X 
{ 

/*...*/ 

struct Ximpi* pimpl_; 

}; 

// Fichier x.cpp 

#include "x.h" 
struct X::XImpl 
{ 

/*. . .mettre ici les membres prives de X */ 
static void* operator new ( size_t ) {/*...*/} 
static void operator delete ( void* ) { /*...*/ } 

}; 

X::X() : pimpl_( new Ximpi ) {} 



1. ...en comparaison avec une operation classique comme un appel de fonction. II est fait 
ici reference aux operateurs d'allocation predefinis ::operator new () et malloc () . 
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X::~X() { delete pimpl_; pimpl_ =0; } 

Les operateurs new() et delete o redefinis pour la structure ximpi doivent etre 
implemented de maniere a gerer un ensemble de blocs pre-alloues et a renvoyer, lors 
d'une demande d' allocation, l'adresse d'un bloc libre : ceci permet de gagner nette- 
ment en performance par rapport a une allocation dynamique normale. A des fins de 
reutilisation, on implemente en general une classe utilitaire separee contenant des 
fonctions d' allocation et de deallocation auxquelles 1' implementation des operateurs 
new ( ) et delete ( ) redefinis fait appel : 

template<size_t S> 
class FixedAllocator 
{ 

public : 

void* Allocate (); // Renvoie l'adresse d'un bloc de taille S 
void Deallocate) void* ); // ^Libere' le bloc 
private : 

/*. . . Liste de blocs memoires definis (« static ») . . .*/ 

}; 

L' implementation ne sera pas detaillee ici, cette technique courante de pre-alloca- 
tion etant decrite dans de nombreux ouvrages C++. 

Neanmoins, il faut signaler un danger potentiel de la classe FixedAllocator ci- 
dessus : si la partie privee utilise des variables statiques pour les blocs memoires pre- 
alloues, ceci peut poser un probleme si la fonction Deallocate ( ) est appelee depuis le 
destructeur d'un objet statique - l'ordre de destruction des variables statiques lors de 
la fin de l'execution d'un programme etant indetermine. Une meilleure implementa- 
tion, eliminant ce type de risque, serait d'utiliser d'un objet membre gerant lui-meme 
une liste de blocs memoire statiques : 

class FixedAllocator 
{ 

public : 

static FixedAllocator & Instance (); 
void* Allocate ( size_t ) ; 
void Deallocate ( void* ) ; 
private : 

/*... objet membre gerant une liste de blocs ...*/ 
}; 

Pour une efficacite optimale, il est judicieux de gerer plusieurs listes de blocs pre- 
alloues de taille differente (par exemple, de 8, 16, 32 octets...) : on parle souvent alors 
d'arene memoire (memory arena). Enfin, l'ideal est de definir une classe de base 
implementant les operateurs new ( ) et delete ( ) en fonction de la classe FixedAlloca- 
tor, de laquelle on fera deriver ximpi : 

struct FastArenaOb ject 
{ 

static void* operator new ( size_t s ) 
{ 

return FixedAllocator : : Instance () ->A1 locate ( s ) ; 

} 
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static void operator delete ( void* p ) 
{ 

FixedAl locator : : Instance () ->Deallocate (p) ; 

} 

}; 

Nous aboutissons ainsi a un ensemble de classes reutilisables permettant d'imple- 
menter la technique dite du « Pimpl rapide » : 

// II suffit de faire deriver Xlmpl de 
// la classe FastArenaOb ject : 

struct X::XImpl : FastArenaOb ject 
{ 

/* . . .Membres prives de X...*/ 

}; 

Ce qui permet d'obtenir une version optimisee de notre exemple initial : 

// Fichier y.h 

class X ; 
class Y 
{ 

/*...*/ 

X* px_; 

>; 

// Fichier y . cpp 

tinclude "x.h" // A present, X derive de FastArenaOb ject 

Y: : Y () : px_ ( new X ) { } 

Y::~Y() { delete px_; px_ =0; } 

Cette technique permet de diminuer nettement le temps utilise pour les operations 
d' allocation. Mais attention, ce n'est pas une solution parfaite ! La contrepartie de ce 
gain de performance est une utilisation memoire superflue et une fragmentation 
accrue dues aux blocs de memoire pre-alloues. 

En conclusion, reservez l'emploi de la technique du « Pimpl » en general et de 
celle du « Pimpl rapide » en particulier aux situations ou les gains apportes sont nota- 
bles par rapport aux contreparties imposees. Ce conseil vaut d'ailleurs pour n'importe 
quel type d' optimisation. 



Recommandation 

Evitez les optimisations superflues sauf lorsque la recherche de la performance maximale 
est une contrainte majeure. 
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Les dangers de ('optimisation a tout-va 

Nous detaillons ici les raisons pour lesquelles la variante n° 2 est extremement 
dangereuse et doit absolument etre evitee. Ce paragraphe a ete clairement separe de la 
solution du probleme afin de bien signaler au lecteur qu'il s'agit d'un code cite a titre 
de contre-exemple, qu'il ne faut surtout pas employer. 

Reprenons le code en question : 

// Fichier y.h : EXEMPLE A NE PAS SUIVRE 

class Y 
{ 

/*...*/ 

static const size_t sizeofx = /* une certaine valeur*/; 
char x_[sizeofx] ; 

}; 

// Fichier y . cpp : EXEMPLE A NE PAS SUIVRE 
tinclude "x.h" 

Y: :Y() 

{ 

assert ( sizeofx >= sizeof (X) ) ; 
new (&x_[0]) X; 

} 

Y: :~Y() 

{ 

(reinterpret_cast<X*> (&x_[0] ) ) ->~X () ; 

} 

CE CODE EST DANGEREUX ! Certes, il optimise l'espace memoire et les temps 
d'allocation 1 . Certes, il est possible qu'il fonctionne correctement sur votre compilateur. 
Cependant, il n'est pas portable, difficile a maintenir et surtout, il peut s'averer catastro- 
phique a 1' execution, et ceci de maniere erratique et imprevisible. En voici les raisons : 

1 . Alignement. La memoire alloue dynamiquement par new ( ) ou maiioc ( ) est correcte- 
ment alignee. En revanche, il n'est pas du tout assure qu'un tableau statique le sera : 

char* bufl = (char* ) malloc ( sizeof (Y) ) ; 
char* buf2 = new char [ sizeof (Y) ]; 
char buf 3 [ sizeof (Y) ]; 

new (bufl) Y; // OK, bufl est alloue dynamiquement (a) 

new (buf2) Y; // OK, buf2 est alloue dynamiquement (b) 

new (Sbuf3[0]) Y; // Erreur, buf3 risque de ne pas etre 

// correctement aligne (c) 
(reinterpret_cast<Y*> (bufl) ) ->~Y () ; // OK 
(reinterpret_cast<Y*> (buf 2) ) ->~Y () ; // OK 
(reinterpret_cast<Y*> (&buf3 [0] ) ) ->~Y () ; // Erreur ! 



1 . En revanche, il limite un peu les avantages apportes par le pimpl_, dans la mesure ou le 
code client doit etre recompile si la valeur de sizeofximpl change ! 
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Les lignes (a) et (b) ne sont pas ideales. En revanche, elles sont techniquement 
correctes, alors que la ligne (c) presente un risque d'erreur a 1' execution, d'autant 
plus sournois qu'il est possible que le code s' execute parfois correctement aux 
moments ou vous avez de la chance 1 . 

2. Fragilite. Une telle implementation impose de nombreuses contraintes au niveau 
de la classe X ! Par exemple, l'auteur de X doit obligatoirement redefinir l'opera- 
teur d' affectation - ou alors, interdire 1' affectation 2 . D'une maniere generale, il 
faudrait s' assurer, pour chaque fonction membre, que son implementation est 
compatible avec l'emploi du tableau statique pimpi_, au risque de rendre la classe 
X inutilisable ! 

3. Cout de maintenance. Lorsque la taille de ximpi varie, il faut modifier en 
consequence la valeur de sizeofximpi et recompiler le code client, ce qui ne faci- 
lite pas la maintenance. 

4. Inefficacite. Pour limiter le cout de maintenance, on pourrait fixer pour 
sizeofximpi une valeur deliberement grande, ce n'est pas non plus une bonne 
solution car cela gaspille inutilement de l'espace memoire. 

5. Mauvais style de programmation. Ce n'est pas certes pas un argument technique, 
neanmoins, il n'est en general pas bon signe de voir un developpeur faisant appel a 
des trues et astuces telle l'allocation d'objets au sein d'un tableau de caracteres ou 
1' affectation en utilisant un operateur new o qui force l'adresse d' allocation et 
l'appel explicite d'un destructeur (voir a ce sujet le probleme n° 41 pour une liste 
des consequences facheuses pouvant survenir). 

En conclusion, l'emploi d'un tableau statique d' octets dans lequel on alloue un 
objet dynamiquement en forcant l'adresse d' allocation est a eviter absolument ! 



1. Pour etre honnete, il existe un moyen de resoudre ce probleme d'alignement : il suffit de 
remplacer la variable membre pimpl_ par une union du type « union { max_align 
m, char pimpl_ [ sizeofximpi ] ; }; ». Neanmoins, ceci ne resoud pas les autres 
problemes exposes ci-dessous ! 

2. II faut egalement s' assurer que cet operateur se comporte correctement en presence 
d'exceptions. A ce sujet, voir les problemes 8 a 17. 
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Pb n° 31. Resolution de noms, principe 

d'interface (1 re partie) Difficulte : 9 1/2 



Lorsque vous appelez une fonction qui a ete surcharged - autrement dit, qui existe sous plu- 
sieurs occurrences portant le meme nom - le compilateur determine quelle fonction appeler 
suivant un algorithme de resolution de noms, dont la logique reserve parfois quelques sur- 
prises. 



Examinez l'exemple de code ci-dessous. Determinez quelles sont les fonctions 
appelees et pourquoi. Quelles conclusions pouvez-vous en tirer ? 

namespace A 
{ 

struct X; 
struct Y; 
void f ( int ) ; 
void g ( X ) ; 



namespace B 
{ 

void f ( int i ) 
{ 

f( i ); // Quelle fonction f() ? 

} 

125 
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void g ( A: :X x ) 
{ 

g ( x ) ; // Quelle fonction g() ? 

} 

void h ( A: : Y y ) 
{ 

h ( y ) ; // Quelle fonction h() ? 




Deux des trois cas sont relativement simples. En revanche, le troisieme requiert 
une bonne maitrise des mecanismes de resolution des noms en C++, notamment la 
connaissance de la « regie de Koenig ». 

Commencons par les cas faciles : 

namespace A 
{ 

struct X; 
struct Y; 
void f ( int ) ; 
void g ( X ) ; 

} 

namespace B 
{ 

void f ( int i ) 
{ 

f( i ); // Quelle fonction f() ? 



La fonction f ( ) s'appelle elle-meme de maniere recursive, car l'autre fonction f ( ) 
declaree au sein de l'espace de nommage a n'est pas visible depuis b. Si l'auteur du 
programme avait ajoute « using a » ou « using a: : f », alors la fonction A: : f (int) 
aurait ete prise en compte lors de resolution de noms - ce qui aurait d' ailleurs conduit 
a une ambiguite que le compilateur n' aurait pas reussi a resoudre. 

Le cas de la fonction g ( ) est un peu plus subtil : 

void g ( A: :X x ) 
{ 

g( x ) ; // Quelle fonction g() ? 



Cet appel de fonction est ambigu et provoquera une erreur de compilation, a moins 
que le developpeur ne precise explicitement laquelle des deux fonctions a : : g ( ) ou 
b : : g ( ) il souhaite appeler. 

Pourquoi cette difference avec le premier cas ? A premiere vue, on pourrait penser 
qu'en l'absence de declaration « using a » dans b, il n'y a aucune raison que a : : g ( ) 
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soit vue depuis b. C'est pourtant le cas, en vertu d'une regie particuliere utilisee lors 
de la resolution de noms : 

Regie de Koenig 1 (simplifiee) : 

Lors de I'appel d'une fonction prenctnt en parametre un argument de type 
objet (en /'occurrence x, de type a: :x), le compilateur fait egalement 
intervenir, dans I'algorithme de resolution de noms, les fonctions de 
I'espace de nommage ou est declare le type de cet argument (en I'occur- 
rence a). 

Voici un autre exemple d' application de la regie de Koenig : 

namespace NS 
{ 

class T { } ; 
void f (T) ; 

} 

NS : : T parm; 
int main ( ) 
{ 

f(parm); // Appelle NS : : f ( ) 

} 

Si elle peut avoir des implications relativement subfiles dans certains cas (notam- 
ment au niveau de 1' isolation des espaces de nommage et de 1' analyse des dependan- 
ces entre classes, que nous aurons l'occasion d'aborder dans le probleme suivant), la 
regie de Koenig n'en demeure pas moins essentielle (pour vous en convaincre, il suffit 
de remplacer, dans l'exemple de code ci-dessus, ns par std, t par string et f par 
operator<< et d'imaginer ce qui se passerait si cette regie n'existait pas) 

Finissons par le troisieme cas, facile celui-ci : 

void h ( A: : Y y ) 
{ 

h( y ); // Quelle fonction h()? 

} 

} 

II n'y a qu'une seule fonction h(), done la fonction h() s' appelle de maniere 
recursive, a 1'infini. La regie de Koenig s' applique - la fonction h ( ) prenant en argu- 
ment un parametre de type a : : y declare dans a, les fonctions de a sont etudiees au 
moment de la resolution des noms, mais aucune ne correspond a la signature de 

B: :h(). 

Quelles conclusions peut-on en tirer? 

Resumons la situation : le comportement d'une fonction contenue dans un espace 
de nommage b est rendu dependant d'une fonction contenue dans un autre espace de 
nommage a, completement independant du premier, par le simple fait qu'elle prend un 
argument dont le type est declare dans A. Ceci signifie que les espaces de nommage 



1 . Du nom de son auteur Andrew Koenig, membre eminent de l'equipe C++ d' AT&T et du 
comite du normalisation C++. Voir aussi Koenig97. 
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ne sont pas aussi independants qu'il n'y parait ! Bien entendu, il ne s'agit pas ici de 
remettre en question cette fonctionnalite tres utile du langage - qui remplit en general 
tres bien son role d' isolation - mais uniquement de signaler, dans ce probleme et le 
suivant, les quelques rares cas dans lesquels les espaces de nommage ne sont pas her- 
metiquement independants. 



Pb n° 32. Resolution de noms, principe d'interface 

(2 e partie) Difficulte : 9 



Quel signifie veritablement le terme « classe » en C++ ? Qu'est-ce est l'« interface » d'une 
classe ? 



Considerons la definition traditionnelle d'une classe : 

« Une classe est constitute d'un ensemble de donnees et de fonctions 
manipulant ces donnees » 

Quelles sont les fonctions qui, selon vous, font partie d'une classe ? Quelles sont 
celles qui constituent, au sens large, l'interface de cette classe ? 

Indice n° 1 : II est clair que les fonctions membres non statiques font partie inte- 
grante de la classe et que les fonctions membres publiques non statiques constituent, 
au moins en partie, l'interface de la classe. Qu'en est-il des fonctions membres stati- 
ques et des fonctions globales ? 

Indice n° 2 : Inspirez-vous de la solution du probleme n° 31 



Solution 



Au-dela de la question posee, nous examinerons egalement, pour approfondir le 
sujet, un ensemble de questions qui lui sont relatives : 

■ Peut-on programmer « objet » en C ? 

■ La notion d'interface de classe est-elle coherente avec la regie de Koenig et avec 
l'exemple de Myers (qui sera decrit dans ce probleme) ? 

■ Quel impact cette notion d'interface a-t-elle sur 1' analyse des dependances entre 
classes d'un programme et sur la conception oriente-objet en general ? 

« Une classe est constitute d'un ensemble de donnees et de fonctions 
manipulant ces donnees » 

Les developpeurs ont souvent tendance a mal interpreter cette definition, la resu- 
mant hativement par : « Une classe, c 'est un ensemble de variables membres et de 
fonctions membres ». 
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Ce n'est pas si simple que cela. Prenez l'exemple suivant : 

//*** Exemple 1 (a) 
class X { /*...*/ } ; 
/*...*/ 

void f ( const Xs ) ; 

A la question « f ( ) fait-il partie de la classe x », beaucoup de developpeurs repondent 
immediatement : « Non, car f { ) n'est pas une fonction membre de x ». D 'autres reali- 
sent que, finalement, l'exemple ci-dessus n'est pas foncierement different de celui-ci : 

//*** Exemple 1 (b) 

class X 

{ 

/*...*/ 

public : 

void f ( ) const ; 

}; 

Aux droits d'acces pres 1 , la fonction to est conceptuellement identique dans les 
deux exemples. La seule difference de forme est que, dans le premier cas, elle prend 
en parametre une reference constante explicite vers x, alors que dans le second cas, 
elle prend un pointeur constant implicite vers x (this). 

Conceptuellement parlant, la fonction f ( ) du premier exemple semble fortement 
liee a x : elle effectue une operation sur x et est situee dans le meme fichier en-tete 
que la declaration de x. 

C'est surtout ce deuxieme point qui est determinant, si la fonction f on'avait pas 
ete situee dans le meme fichier en-tete que x, ce ne serait qu'une fonction globale uti- 
lisatrice de x comme une autre (ce n'est pas parce qu'on ecrit une fonction prenant en 
parametre une classe declaree dans la bibliotheque standard qu'on modifie 1' interface 
de cette classe). 

Ceci nous conduit a l'enonciation du « Principe d'interface » : 

L'interface d'une classe x est constitute de toutes les fonctions, membres 
ou globales, qui « font reference a x » et « sont fournies avec x ». 

En d'autres termes, l'interface d'une classe est Fensemble des fonctions qui sont 
conceptuellement rattachees a cette classe. 

Notons que toutes les fonctions membres d'une classe font partie de l'interface de 
cette classe : en effet, chaque fonction membre « fait reference a x » (les fonctions 
membres non statiques prennent un parametre implicite de type x* ou const x*, les 
fonctions membres statiques sont dans la portee de x) et « est fournie avec x » (fait 
partie de la definition de x). 

Etudions maintenant le cas de notre fonction f()de l'exemple i(a): f() 
« fait reference a x » (elle prend un parametre de type const xs) et f() est « fournie 
avec x » car elle est dans le meme fichier en-tete que la declaration de x. Par 
consequent, on peut considerer que f ( ) fait partie de la classe x. 



1. Et encore, il serait possible de declarer f ( ) amie de x dans l'exemple 1(a). 
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Remarque : on peut considerer qu'une fonction globale « fait partie » d'une classe 
lorsqu'elle est declaree dans le meme fichier en-tete ou dans le meme espace de nom- 
mage que cette classe 1 . 

Ainsi, 1' interface de classe est 1' ensemble des fonctions qui font conceptuellement 
partie de cette classe. Comme le montre l'exemple suivant, il est done tout a fait possi- 
ble qu'une fonction globale (non membre, done) fasse « partie » d'une classe : 

I/*** Exemple 1 (c) 
class X { /*...*/ } ; 
/*...*/ 

ostreamS operator<< ( ostreamS, const XS ); 

Ici, l'auteur de la classe x fournit une implementation specifique de l'operateur << 
permettant d'afficher les valeurs d'un objet de type x. Cet operateur doit etre imple- 
mente sous la forme d'une fonction globale car il n'est pas possible de modifier la 
declaration de la classe ostream de la bibliotheque standard. II est clair que l'opera- 
teur << est rattache conceptuellement a la classe x car sans lui, les fonctionnalites de 
la classe X seraient moindres. Eh bien cet exemple ne differe en rien des deux prece- 
dents : operator« fait reference ax et est fournie avec x, done fait partie de x. Atten- 
tion, les deux conditions doivent etre remplies ! A titre de contre-exemple, 
operator<< fait reference a ostream mais n'est pas fournie avec ostream, done ope- 
rators ne fait pas partie de ostream 2 . 

Revenons a notre definition initiale du terme « classe » : 

« Une classe est constitute d'un ensemble de donnees et de fonctions 
manipulant ces donnees » 

On ne peut, en conclusion, que constater que cette definition est parfaitement juste, 
les « fonctions » mentionnees pouvant tout a fait etre membres ou ne pas l'etre. 

Continuons a nous interroger sur cette notion d'interface de classe. Est-elle specifique 
au C++ ? Ou est-ce un concept oriente objet pouvant s'appliquer a d'autres langages ? 

Interessons-nous a l'exemple de code suivant, qui n'est pas ecrit en C++ mais dans 
un autre langage - non oriente objet - qui devrait vous etre familier : 

/*** Exemple 2 (a) ***/ 

struct _iobuf { /* . . . contient les donnees...*/ } ; 

typedef struct _iobuf FILE; 

FILE* fopen ( const char* filename, 

const char* mode ) ; 
int fclose ( FILE* stream ) ; 
int fseek ( FILE* stream, 

long offset, 

int origin ) ; 



1 . Nous etudierons dans la suite de ce chapitre les relations entre interface de classe et espace 
de nommage, et notamment leur lien avec la regie de Koenig etudiee precedemment. 

2. La similarite entre fonctions membres et non membres est encore plus marquee pour 
certains autres operateurs. Par exemple, a+b peut faire reference soit a . operator+ (b) 
soit a operator+ (a, b) en fonction des types de a et b. 
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long ftell ( FILE* stream ) ; 
/* etc. */ 

Nous avons ici un exemple typique de code « oriente-objet » ecrit dans un langage 
qui ne Test pas : une structure contenant la definition de donnees et un ensemble de 
fonctions permettant de manipuler ces donnees, qui prennent un argument ou ren- 
voient un pointeur vers cette structure. Dans notre cas, la structure FILE represente un 
fichier et les fonctions associees permettent respectivement de construire (f open), de 
detruire (f close) ou de manipuler (f seek, ftell,...) un fichier. 

Bien entendu, le langage C n'offre pas le meme niveau de confort que le C++, 
notamment au niveau de 1' encapsulation (rien n'empeche le code client de faire mani- 
puler directement les donnees). Neanmoins, conceptuellement parlant, on peut tout a 
fait considerer que file est une classe et que les fonctions fopen, f close, etc. font 
partie de la classe. 

Reprenons le meme exemple, en C++ cette fois : 

//*** Exemple 2 (b) 

class FILE 

{ 

public : 

FILE ( const char* filename, 
const char* mode ) ; 
-FILE () ; 

int f seek ( long offset, int origin ) ; 
long ftell () ; 

/* etc. */ 
private : 

/* . . . contient les donnees . . . */ 

}; 

Les parametres file* des fonctions devenues membres ont ete remplaces par des 
parametres implicites this. 

On aurait egalement tout a fait pu choisir de rendre certains fonctions non mem- 
bres : 

//*** Exemple 2 (c) 

class FILE 

{ 

public : 

FILE ( const char* filename, 
const char* mode ) ; 
-FILE () ; 
long ftell () ; 

/* etc. */ 
private : 

/*. . .contient les donnees. . .*/ 

}; 

int fseek ( FILE* stream, 
long offset, 
int origin ) ; 
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La fonction f seek o fait reference a file et est fournie avec file ; elle fait par 
consequent partie de l'interface de file. 

Dans l'exemple 2(a), toutes les fonctions etaient globales car le langage C ne nous 
laissait pas d' autre choix. Mais en C++ egalement, il est tout a fait courant que certaines 
fonctions fassent partie de l'interface d'une classe sans pour autant etre membres de 
cette classe : par exemple, l'operateur << ne peut pas etre membre car son operande de 
gauche est obligatoirement de type ostream ; de meme, l'operateur + ne doit en general 
pas etre membre de maniere a autoriser les conversions sur son operande de gauche 1 . 
Ces operateurs n'en font pas moins partie de la classe a laquelle ils se referent. 

Retour sur la regie de Koenig 

La notion d'interface de classe telle que nous l'avons definie dans le paragraphe 
precedent est totalement coherente avec la regie de Koenig. 

Rappelons brievement cette regie : 

//*** Exemple 3 (a) 

namespace NS 

{ 

class T { }; 
void f (T) ; 

} 

NS : : T parm; 
int main ( ) 
{ 

f(parm); // Appelle NS : : f ( ) 

} 

II parait ici « naturel » que ce soit la fonction ns : : f ( ) qui soit appelee depuis 
main ( ) . Pourtant, ce n'est pas evident a priori, cette fonction etant situee dans un autre 
espace de nommage (ns) et on pourrait s'attendre a ce que le compilateur exige une 
instruction « using namespace ns » pour prendre en compte ns : : f ( ) lors de la reso- 
lution de noms. 

La regie de Koenig nous assure ici que la fonction ns : : f ( ) sera appelee sans qu'il 
soit necessaire d'utiliser une instruction « using ». En effet, cette regie enonce que le 
compilateur doit, lors la resolution de noms pour l'appel d'une fonction, prendre en 
compte les fonctions contenues dans les espaces de nommage ou sont declares les 
types des parametres de cette fonction. Par exemple, le compilateur prend ici en 
compte les fonctions de ns car f() prend un parametre de type ns : : t, defini dans ns. 

Voici un autre exemple ou la regie de Koenig s'avere bien utile : 

//*** Exemple 3 (b) 
#include <iostream> 

#include <string> // contient la declaration de 
// std : : operator<< pour string 



1 . Voir le probleme n° 20. 
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int main () 
{ 

std::string hello = "Hello, world"; 

std::cout << hello; // Appelle std : : operator« 

// grace a la regie de Koenig 

} 

Grace a la regie de Koenig, le compilateur prend en compte automatiquement les 
fonctions de l'espace de nommage ou est declaree string (c'est-a-dire std) pour la 
resolution de l'appel « std : : cout<<hello ; ». 

Sans cette regie, il y aurait la solution d'ajouter une instruction « using 
std : :operator<< ; » en haut de chaque module concerne, ce qui deviendrait vite 
fastidieux dans le cas de plusieurs operateurs ; d'utiliser « using namespace std ; », 
ce qui aurait pour effet de copier tous les noms de std dans l'espace de nommage par 
defaut et, par la-meme, de supprimer tout l'interet de 1' utilisation des espaces de nom- 
mage ; ou bien encore de faire explicitement reference a la fonction 
« std: :operator<< (std: :cout, hello) ; » ce qui obligerait a se priver de la syn- 
taxe habituelle des operateurs, pourtant tres confortable. Aucune de ces solutions n'est 
viable, ceci demontre bien a quel point la regie de Koenig est pratique ! 

En resume, lorsque vous definissez, dans un meme espace de nommage, une classe 
et une fonction globale faisant reference a cette classe 1 , le compilateur va en quelque 
sorte etablir une relation entre les deux. 2 Ceci nous ramene a la notion d'interface de 
classe, comme l'exemple de Myers va nous le montrer. 

Regie de Koenig, suite et fin : l'exemple de Myers 

Considerons l'exemple suivant - legerement modifie par rapport au 3(a) : 

//*** Exemple 4 (a) 

// Fichier t.h 
namespace NS 
{ 

class T { }; 

} 

// Fichier main.cpp 

void f ( NS : : T ) ; 

int main ( ) 
{ 

NS : : T parm; 

f (parm) ; // OK: calls global f 

} 



1 . Par valeur, reference, pointeur ou autre. 

2. Certes moins forte que la relation existant entre une classe et une de ses fonctions mem- 
bres. A ce sujet, voir le paragraphe « 'Etre membre' ou 'faire partie' d'une classe » plus 
loin dans ce chapitre. 
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D'un cote, nous avons une classe t definie dans un espace de nommage ns, de 
1' autre, nous avons un code client utilisant T et definissant, pour ses propres besoins, 
une fonction globale f ( ) utilisant t. Pour l'instant, rien a signaler... 

Que se passe t'il si, un jour, l'auteur de « t . h » decide d'ajouter une fonction f ( ) 
dans ns ? 

//*** Exemple 4 (b) 

// Fichier t.h 
namespace NS 
{ 

class T { }; 

void f ( T ) ; // < — Nouvelle fonction 

} 

void f ( NS : :T ) ; 

int main ( ) 

{ 

NS : : T parm; 

f (parm) ; // Appel ambigu : Appelle NS : : f 

} // ou la fonction globale f ? 

Le fait d'ajouter une fonction f o a Vinterieur de l'espace de nommage ns a 
rendu inoperant du code client exterieur a ns, ce qui peut paraitre plutot genant. Mais 
attendez, il y a pire : 

//*** Exemple de Myers: "Avant" 

namespace A 
{ 

class X { } ; 

} 

namespace B 
{ 

void f ( A: :X ) ; 
void g( A::X parm ) 
{ 

f(parm); // OK: Appelle B::f() 

} 

} 

Pour l'instant, tout va bien. Jusqu'au jour ou l'auteur de a ajoute une nouvelle 
fonction : 

//*** Exemple de Myers: "Apres" 

namespace A 
{ 

class X { } ; 

void f ( X ) ; // < — Nouvelle fonction 

} 

namespace B 
{ 

void f ( A: :X ) ; 
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void g( A: :X parm ) 
{ 

f (parm) ; // Appel ambigu : A::f ou B::f ? 

} 

} 

La encore, le fait d'ajouter une fonction a l'interieur de a peut rendre inoperant du 
code exterieur a a. A premiere vue, ceci peut paraitre plutot genant et contraire aux 
principes meme des espaces de nommage, dont la fonction est A'isoler differentes par- 
ties du code. C'est d'ailleurs d'autant plus troublant que le lien entre le code concerne 
et a n'est pas clairement apparent. 

Si on y reflechit un peu, ceci n'est pas un probleme, au contraire ! II se passe exac- 
tement ce qui doit se passer 1 . II est tout a fait normal que la fonction f (X) de a inter- 
vienne dans la resolution de 1' appel f (parm) - et, en Foccurrence, cree une ambiguite. 
Cette fonction fait reference a x et est fournie avec x, done, en vertu du principe de 
1' interface de classe, elle fait partie de la classe x. A la limite, peu importe que f o 
soit une fonction globale ou une fonction membre, l'important est qu'elle soit ratta- 
chee conceptuellement a x. 

Voici une autre version de l'exemple de Myers : 

//*** Exemple de Myers : "Apres" (autre version) 

namespace A 

{ 

class X { } ; 

ostreams operator<< ( ostreams, const X& ); 

} 

namespace B 
{ 

ostreams operator<< ( ostreams, const A::XS ); 

void g( A: :X parm ) 

{ 

cout << parm; // Appel ambigu : A: :operator<< 
} // ou B : : operator<< ? 

} 

Une fois encore, il est normal que l'appel cout«parm soit ambigu. L'auteur de la 
fonction g ( ) doit explicitement indiquer quelle fonction operator<< il souhaite appe- 
ler, celle de b - qu'il est normal de prendre en compte car elle est situee dans le meme 
espace de nommage - ou celle de a - qu'il est egalement normal de prendre en compte 
car elle « fait partie » de x, au nom du principe d'interface de classe : 

L'interface d'une classe x est constitute de toutes les fonctions, membres 
ou globales, qui « font reference a x » et « sont fournies avec x ». 

L'exemple de Myers a le merite de montrer que les espaces de nommage ne sont 
pas aussi independants qu'on le croit mais egalement que cette dependance est saine 



1 . C'est cet exemple, cite a la reunion du Comite de Normalisation C++ en novembre 1997 
a Morristown, qui m'a amene a reflechir sur le sujet des dependances en general. 
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et voulue. : ce n'est pas un hasard que la notion d'interface de classe soit coherente 
avec la regie de Koenig. Cette regie a justement ete etablie en vertu de cette notion 
d'interface de classe. 

Pour etre complet sur le sujet, nous allons maintenant voir en quoi « etre membre » 
d'une classe introduit une relation plus forte qu'etre une fonction globale « faisant partie 
de la classe ». 



« Etre membre » ou « faire partie » d'une classe 

Le principe d'interface de classe enonce que des fonctions membres et non-mem- 
bres peuvent toutes deux faire conceptuellement « partie » d'une classe. II n'en 
conclut pas pour autant que membres et non-membres sont equivalents. II est clair 
qu'une fonction membre est liee de maniere plus forte a une classe car elle a acces a 
l'ensemble des membres prives alors que ce n'est pas le cas pour une fonction globale 
- a moins qu'elle ne soit declaree comme friend. De plus, lors d'une resolution de 
nom - faisant appel ou non a la regie de Koenig, une fonction membre prend toujours 
le pas sur une fonction globale : 

// Ceci n'est PAS l'exemple de Myers 

namespace A 
{ 

class X { } ; 
void f(X) ; 

} 

class B // 'class' , pas 'namespace' 

{ 

void f (A: :X) ; 
void g(A::X parm) 
{ 

f(parm) ; // Appelle B::f(), pas d' ambiguite 




Dans cet exemple, la classe b contenant une fonction membre f (A: :X) , le compi- 
lateur fait appeler cette fonction, ne cherchant meme pas a regarder ce qui est dans a, 
bien que f prenne un parametre dont le type est declare dans a. 

En resume, une fonction membre est toujours plus fortement liee a une classe 
qu'une fonction non-membre - meme faisant « partie » de la classe au nom de la 
notion d'interface de classe - notamment pour ce qui concerne 1' acces aux membres 
prives et la resolution des noms. 
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Dans ce probleme, nous allons mettre en pratique la notion d'interface de classe en I'appliquant 
tout d'abord a une question courante : quelle est la meilleure maniere d'implementer la fonc- 
tion operator« ( ) ? Nous verrons egalement les consequences de ce principe au niveau de la 
phase de conception des programmes. 



II y a en general deux manieres courantes d'implementer l'operateur << : soit 
comme une fonction globale utilisant l'interface publique de classe (ou a la limite, 
l'interface non-publique, si elle est declaree comme friend) ou comme une fonction 
globale appelant une fonction membre virtuelle Print ( ) . 

Quelle est la meilleure methode ? Precisez les avantages et inconvenients de 
chacune. 




Une des consequences pratiques de la notion d'interface de classe est qu'elle per- 
met d' identifier clairement les dependances entre une classe et ses « clients ». 

Nous allons voir ici 1 'exemple concret de la fonction operator<<. 

Classes et dependances 

II y a classiquement deux manieres d'implementer l'operateur «. 

La premiere consiste a utiliser une fonction globale faisant appel a l'interface de la 
classe : 

//*** Exemple 5 (a) - sans fonction virtuelle 

class X 

{ 

/*. . .aucune reference a ostream ...*/ 

}; 

ostreams operator<< ( ostreams o, const Xs x ) 
{ 

/* Code realisant l'affichage de X dans o */ 
return o; 

} 

La seconde consiste a utiliser une fonction virtuelle : 

//*** Exemple 5 (b) - avec fonction virtuelle 

class X 

{ 

/*...*/ 
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public : 

virtual ostreamS print ( ostrearaS ) ; 

>; 

ostreamS X::print( ostreamS o ) 
{ 

/* Code realisant l'affichage de X dans o */ 
return o; 

} 

ostreamS operator<< ( ostreamS o, const Xs x ) 
{ 

return x. print ( o ) ; 

} 

Traditionnellement, les developpeurs C++ analysent ces deux options de la 
maniere suivante : 

■ L' option (a) presente deux avantages : d'une part, elle minimise les dependances - 
la classe x ne depend pas (ou ne semble pas dependre...) de ostream, car ce type 
n'apparait pas dans 1' interface de x, d' autre part, elle economise le surcout d'un 
appel de fonction virtuelle. 

■ L' option (b) presente l'avantage d'etre compatible avec les classes derivees : un 
code client manipulant X de maniere polymorphique (xs ou x* referencant un 
objet derive de x) se comportera correctement si la fonction Print o est redefinie 
dans la classe derivee. 

Ceci est F analyse traditionnelle, malheureusement trompeuse. Nous allons mainte- 
nant voir que le reexamen de la question a la lumiere de la notion d'interface de classe 
conduit a une conclusion tout a fait differente : en realite - ainsi que le commentaire en 
italique le laissait entendre - la classe x de l'option (a) est dependante de ostream 

Voici le raisonnement permettant d'aboutir a cette conclusion : 

■ Dans les options (a) et (b), la fonction operator<< ( ) « fait reference » a la classe 
x et « est fournie avec » x : elle fait done conceptuellement partie de la classe x 
dans les deux cas. 

■ Dans les deux cas, operator<< ( ) fait reference a ostream. 

■ Par consequent, dans les options (a) et (b), x depend de ostream car, dans les deux 
cas, une fonction faisant partie de la classe fait reference a ostream. 

Autrement dit, l'avantage principal de l'option (a) est caduc. Dans les deux cas, il 
est necessaire d'avoir une declaration de ostream dans le fichier en-tete « x.h » - 
comme en general, 1' implementation de l'operateur << est dans le fichier source, une 
declaration « en avance » suffit. 

En resume, l'unique avantage de l'option (a) est done d'economiser le surcout 
d'un appel de fonction virtuel. Ceci est plutot mince au regard de l'avantage procure 
par l'option (b). Ainsi, grace a 1' application du principe d'interface de classe, nous 
avons pu determiner les veritables dependances entre classes : il apparait des lors clai- 
rement que la meilleure des options est l'utilisation d'une fonction Print ( ) virtuelle. 

Nous avons vu ici un exemple pratique d' application de la notion d'interface de 
classe qui nous a permis d' analyser, au-dela de la nature de fonction membre ou non- 
membre, les fonctions faisant veritablement « partie » d'une classe. 
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Quelques resultats interessants... 
et parfois surprenants 

Soient a et b deux classes et f (a, b) une fonction globale : 

■ Si f est fournie avec a, alors f fait partie de a et, par consequent, a depend de b. 

■ Si f est fournie avec b, alors f fait partie de b et, par consequent, b depend de a. 

■ Si a, b et f sont fournies ensemble, alors f fait partie de a et b et, par consequent, 
a et b sont interdependantes. Ce qui etait relativement jusqu' alors intuitif - si 
l'auteur d'une bibliotheque met a disposition deux classes et une fonction utilisant 
les utilisant toutes les deux, il est probable que ces trois elements sont destines a 
etre utilises ensemble - est maintenant clairement justifie par la notion d'interface 
de classe. 

Pour finir, voyons un cas un peu plus subtil. Soient a et b deux classes et A: : g (B) 
une fonction membre de a : 

■ a depend de b, du fait de la fonction membre A: : g (B) . Jusque la, rien de bien sur- 
prenant. 

■ Plus etonnant : si a et b sont fournies ensembles, alors A: :g (b) fait partie de la 
classe b. En effet, dans ce cas, la fonction A: : g (B) est « fournie avec » b et « fait 
reference » a b ; elle fait done « partie de » b. Toujours dans ce cas, les deux clas- 
ses a et b sont done interdependantes. 

II peut certes paraitre etonnant d' avoir une fonction membre d'une classe « faisant 
partie » d'une autre classe. C'est neanmoins ce qui se produit lorsque a et b sont four- 
nies ensemble. L'interdependance entre a et b etait intuitive - il est clair que deux 
classes reunies dans un meme fichier en-tete sont a priori destinees a etre utilisees 
ensemble et que les changements apportes a l'une ont un impact sur 1' autre - elle est 
maintenant clairement identifiee par l'application du principe d'interface de classe. 

Une petite remarque concernant les espaces de nommage et le fait d'etre « fourni 
avec » : 

//*** Exemple 6 (a) 
// Fichier a.h 

namespace N { class B; } // Declaration en avance 
namespace N { class A; } // Declaration en avance 
class N::A { public: void g(B); }; 
// Fichier b.h 

namespace N { class B { /*...*/ } ; } 

Les clients de la classe a incluent le fichier « a . h » : pour eux, a et b sont fournies 
ensembles et sont done interdependantes. Les clients de la classe b, quant a eux, 
incluent « b . h » : pour eux, a et b ne sont pas fournies ensemble. 

En conclusion de cette serie de problemes tournant autour de la notion d'interface 
de classe, voici les principaux points a retenir : 

■ La notion d'interface de classe : V interface d'une classe x est constitute de toutes les 
fonctions, membres ou globales, qui « font reference ax» et « sont fournies avec x ». 
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■ Par consequent, une classe peut etre conceptuellement constitute de fonctions 
membres comme de fonctions non-membres. Neanmoins, les fonctions membre 
sont plus fortement liees a la classe. 

■ Pour une fonction, « etre fourni avec » une classe signifie en general apparaitre dans 
le meme fichier en-tete et/ou le meme espace de nommage que cette classe. Dans le 
premier cas, l'appartenance de la fonction a la classe se manifeste lors de 1' etude des 
dependances ; dans le second cas, elle se manifeste lors de la resolution des noms. 



Pb n° 34. Resolution de noms, interface d'une 

classe (4 e partie) Difficulte : 9 



Pour finir cette serie de problemes consacres a la notion d'interface de classe, nous allons etu- 
dier certains aspects subtils des mecanismes de resolution de nom. 

1. Qu'appelle t-on le « masquage d'une fonction » ? Donnez un exemple de mas- 
quage de fonctions d'une classe de base par une classe derivee. 

2. Examinez le code ci-dessous. Va t-il se compiler correctement ? Sinon, pourquoi ? 

// Exemple 2 : ce code va t-il se compiler correctement ? 
// 

// MonFicher.h : 

namespace N { class C {}; } 

int operatort ( int i, N::C) { return i+1; } 

// Main.cpp 

#include <numeric> 

int main ( ) 

{ 

N : : C a [ 1 0 ] ; 

std: : accumulate (a, a+10, 0); 

} 




Le masquage de noms a deja ete etudie en detail dans le chapitre precedent, 
consacre a 1' heritage. Nous en rappelons ici le principe, en reponse a la premiere ques- 
tion du probleme. 



Masquage de noms 

Considerons le programme suivant : 

// Exemple la: Exemple de fonction 

// masquee par une classe derivee 
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// 



struct B 
{ 

int f ( int ) ; 
int f ( double ) ; 
int g ( int ) ; 



struct D : public B 
{ 

private : 

int g( std :: string, bool ); 

}; 

D d; 
int i; 

d.f(i); // OK : appelle B::f(int) 

d.g(i); // Erreur : g attend deux arguments ! 

Cet exemple produira une erreur de compilation a la ligne « d . g ( i ) » du fait que la 
fonction b : : g ( ) , masquee, n'est pas examinee lors de la resolution de noms. En effet, 
le fait de declarer une fonction dans une classe derivee masque systematiquement 
toutes les fonctions portant le meme nom dans toutes les classes de base directes ou 
indirectes, quelle que soit leur signature. Dans notre exemple, le fait d' avoir une 
fonction g membre de d exclut l'examen par 1'algorithme de resolution de noms de la 
fonction b : : f ( ) : ainsi, la fonction d : : g ( ) attendant deux arguments de type string 
et bool et etant, en outre, privee, une erreur de compilation se produit. 

Pour mieux comprendre cette regie malheureusement ignoree par certains deve- 
loppeurs C++, voyons plus en detail ce qui se passe lors de la resolution de l'appel 
d . g ( i ) : en premier lieu, le compilateur recherche les fonctions g ( ) existantes dans la 
portee de la classe d, sans se preoccuper de leur accessibilite ni de leur nombre de 
parametres. S'il ne trouve aucune fonction nommee g o , et uniquement dans ce cas- 
la, le compilateur recherche des fonctions g ( ) dans les portees proches (la classe de 
base b, en l'occurrence). L' operation est reiteree jusqu'a ce que le compilateur ait 
identifie une portee contenant au moins une fonction candidate - ou, jusqu'a ce que 
l'ensemble des portees possibles ait ete examine, sans succes. Si une portee contenant 
plusieurs fonctions candidates est identifiee, alors le choix entre ces differentes fonc- 
tions est effectue en fonction des droits d'acces et des parametres. 

Cet algorithme se justifie 1 : en effet, pour prendre un cas extreme, il parait intuiti- 
vement incoherent qu'une fonction membre ay ant pratiquement la bonne signature - 
a des conversions de types autorisees pres - soit plus privilegiee qu'une fonction glo- 
bale ayant exactement la bonne signature. 



Eviter les masquage de noms involontaires 

II y a deux techniques courantes pour passer outre le masquage des noms de fonc- 
tions. 
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La premiere consiste a indiquer explicitement au compilateur le nom de la fonc- 
tion a appeler : 

// Exemple 1(b) : Appel explicite 

// d'une fonction de la classe de base 

// 

D d; 
int i ; 

d.f(i); // Appelle B::f(int) (pas de masquage) 

d.B::g(i); // Appelle explicitement B::g(int) 

La deuxieme consiste a indiquer au compilateur qu'il doit examiner b : : g ( ) lors de 
la resolution de nom a l'aide d'une instruction using : 

// Exemple 1(c) : Prise en compte 

// d'une fonction masquee 

// 

struct D : public B 
{ 

using B: :g; 

private : 

int g( std: : string, bool ); 

}; 



Interface de classes et espaces de nommmage 

Etudions maintenant la deuxieme question du probleme, qui va permettre de met- 
tre en lumiere les problemes qui se presentent lorsqu'on declare une classe et des 
fonctions globales qui lui sont liees (comme des operateurs) dans deux espaces de 
nommage differents : 

// Exemple 2: ce code va t'il se compiler correctement ? 
// 

// MonFicher.h : 

namespace N { class C {); } 

int operatort ( int i, N::C) { return i+1; } 
// Main.cpp 
#include <numeric> 
int main ( ) 



1 . On aurait pu imaginer des variantes a cet algorithme. Par exemple, examiner les portees 
successives tant qu'on n'a pas trouve de fonction correspondant a la signature attendue 
- au lieu de se contenter d' avoir trouve une fonction portant le bon nom. Ou encore, 
faire la liste des toutes les fonctions possibles presentes dans toutes les portees disponi- 
bles puis determiner la fonction adequate en fonction des parametres et droits d'acces. 
Ces deux variantes presentent le risque de faire preferer le « lointain » au « proche ». 
Dans le premier cas, on risque, par exemple, de preferer une fonction « lointaine » ayant 
exactement la bonne signature a une fonction proche ayant une signature correcte a 
quelques conversions pres. Dans la deuxieme cas, on risque de provoquer une ambigui'te 
entre une fonction membre et une fonction globale ayant toutes les deux la bonne signa- 
ture, plutot que de preferer la fonction membre. 
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{ 

N: :C a [10] ; 

std :: accumulate (a, a+10, 0); 

} 

Ce programme va t'il se compiler correctement ? Est-il portable 1 ? 



Espaces de nommage et masquage de noms 

A premiere vue, le code ci-dessus semble tout a fait correct. Pourtant, aussi surpre- 
nant que cela puisse paraitre, il risque de ne pas se compiler correctement sur toutes 
les machines, ceci en fonction de 1' implementation de la bibliotheque standard dont 
vous disposez - meme si cette implementation est conforme a la norme C++. 

Quelle est l'explication de ce mystere ? Pour le savoir, voyons de quelle maniere 
est typiquement implementee la fonction accumulate, qui est d'ailleurs en realite un 
modele de fonction : 

namespace std 
{ 

template<class Iter, class T> 
inline T accumulate) Iter first, 

Iter last, 

T value ) 

{ 

while ( first != last ) 

{ 

value = value + * first; 

++f irst ; 

} 

return value; 

} 

} 

Le code de l'exemple (2) appelle la fonction accumulated: :c*, int>. Par 
consequent, lors de resolution de l'appel « value + first », le compilateur recher- 
chera une fonction operatort o acceptant un int et un n: :c en parametres (ou des 
parametres compatibles aux conversions autorisees pres). A priori, c'est done la fonc- 
tion globale operator+o de l'exemple (2), correspondant a cette signature, qui 
devrait etre appelee. 

Malheureusement, il n'est pas certain que cette fonction soit effectivement appe- 
lee : ceci depend des autres fonctions operatort ( ) situees dans l'espace de nommage 
std, rencontrees par le compilateur avant l'instanciation de accumulated: :c*, int>. 



1. II n'y a pas de probleme de portabilite lie au fait que std: : accumulate ( ) risque d'appeler 
soit operatort (N : : C, int ) , soit operator + (int,N::C) en fonction de 1' implemen- 
tation de la bibliotheque standard : la norme C++ specifie clairement que c'est la premiere 
version qui doit etre appelee. A ce titre la, l'exemple 2 est done correct. 
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En effet, rappelons une nouvelle fois de quelle maniere le compilateur effectue la 
resolution des noms lors d'un appel de fonction (on ne fait ici que reprendre les expli- 
cations de la section precedente, adaptees a l'exemple en cours) : en premier lieu, le 
compilateur recherche les fonctions operator+o existantes dans l'espace de nom- 
mage std, sans se preoccuper de leur accessibilite ni de leur nombre de parametres. 
S'il ne trouve aucune fonction nommee operatort ( ) dans std, et uniquement dans ce 
cas-la, le compilateur recherche des fonctions operatort o dans les portees proches 
(l'espace de nommage global, en l'occurrence). L' operation est reiteree jusqu'a ce que 
le compilateur ait identifie une portee contenant au moins une fonction candidate - ou, 
jusqu'a ce que l'ensemble des portees possibles ait ete examine, sans succes. Si une 
portee contenant plusieurs fonctions candidates est identifiee, alors le choix entre ces 
differentes fonctions est effectue en fonction des droits d'acces et des parametres. 

Autrement dit, la reussite de la compilation de l'exemple 2 est totalement depen- 
dante de 1' implementation du fichier en-tete standard <numerio : si ce fichier declare 
une fonction operatort (), quelle qu'elle soit, (independamment de son accessibilite 
ou de ses parametres) ou s'il inclut un autre fichier en-tete declarant operatort o , 
alors cet exemple de code ne se compilera pas. A l'inverse du C, la norme C++ ne spe- 
cific pas explicitement la liste des fichiers en-tete standards inclus par un fichier en- 
tete standard donne : par exemple, en incluant <numeric>, il est probable - mais pas 
certain - que vous inclurez egalement <iterator>, fichier dans lequel sont definies 
plusieurs fonctions operator+ o . Autre exemple, votre programme peut se compiler 
correctement jusqu'au jour ou vous inclurez le fichier en-tete <vector>. En resume, 
ce programme n'est pas portable : il peut tres bien fonctionner avec certains compila- 
teurs C++, mais refuser de se compiler avec d'autres. 

Quand le compilateur s'en mele... 

Non seulement l'exemple 2 risque de ne pas de se compiler correctement, mais 
encore, l'erreur fournie par le compilateur a de fortes chances d'etre une source de 
confusion supplementaire pour le developpeur. Voici, par exemple, le message 
d'erreur obtenu pour l'exemple 2 avec l'un des compilateurs populaires du marche : 

error C2784: 'class std: : reverse_iterator< 'template-parameter- 
1', 'template-parameter-2 ' , 'template-parameter-3' , ^template- 

parameter-4 ' , ^template-parameter-5 ' > cdecl std: : operator 

+ (template-parameter-5, const class 

std : : reverse_iterator< ' temp late -pa r amet e r- 1 ' , ' temp late -par ameter- 
2', 'template-parameter-3' , 'template-parameter-4 ' , 'template- 
parameter-5 ' >& ) ' : could not deduce template argument for 
'template-parameter-5' from 'int' 

error C2677: binary '+' : no global operator defined which takes 
type 'class N::C (or there is no acceptable conversion) 

Ce message d'erreur complexe et peu exploitable est du au modele de fonction 
operator+o rencontre dans le fichier en-tete <iterator> (lui-meme inclus par 
<numerio dans cette implementation de la bibliotheque standard). 
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II n'est pas rare que les erreurs soient peu explicites des que des modeles de clas- 
ses et de fonction rentrent en ligne de compte. Les messages ci-dessus en sont un bon 
exemple : 

■ Le premier message n'est vraiment pas clair : si on comprend finalement, avec peine, 
que le compilateur indique qu'il a trouve une fonction operator+o mais qu'il ne 
comprend pas comment Futiliser, le premier reflexe a la lecture est de se 
demander : « Mais ou done ai-je bien pu faire appel a la classe reverse_iterator ? » 

■ Le second message est faux - une erreur du compilateur, a moitie excusable du fait 
que Futilisation des espaces de nommage est recente et done pas toujours maitri- 
see en profondeur par tous les outils. Le message correct devrait etre « aucun ope- 
rateur '+' global prenant en parametre un n: :c n'a ete trouve » plutot que le 
message actuel « il n'existe aucun operateur '+' global prenant en parametre un 
n : : c », car il en existe bel et bien un ! 

En resume, les messages d' erreurs fournies par le compilateur dans ce genre de 
situation ne sont pas d'une grande aide. L'ideal serait de toute facon de modifier 
1' exemple 2 de maniere a obtenir une implementation portable. Nous allons voir tout 
de suite comment y arriver. 

Comment s'en sortir ? 

Nous avons deja vu deux solutions possibles pour rendre « visible » une fonction 
d'une classe de base masquee depuis la classe derivee : appeler explicitement la fonc- 
tion (Exemple lb) ou utiliser une instruction using (Exemple lc). Aucune de ces deux 
solutions ne fonctionnera ici 1 . 

La seule solution viable est de mettre la fonction operator+o dans le meme 
espace de nommage que la classe a laquelle elle se rattache : 

// Exemple 2b : Solution 

// 

// MonFicher.h : 

namespace N 

{ 

class C { } ; 

int operator+ (int i, N::C) { return i+1; ) 

} 

// Main.cpp 
tinclude <numeric> 
int main ( ) 
{ 

N: :C a [10] ; 

std :: accumulate (a, a+10, 0); // Maintenant, ca fonctionne ! 

} 



1 . Pour etre honnete, la premiere solution est techniquement possible mais tres lourde pour 
le developpeur, Fobligeant, a chaque appel, a faire reference explicitement au modele 
de fonction std: : accumulate en precisant ses parametres d'instantation. 
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Ce code est, cette fois, tout a fait portable et fonctionne avec toute implementation 
conforme de la bibliotheque standard, independamment des fonctions operator+o 
definies ou non dans l'espace de nommage std ou un autre. Comme operatort o est 
situe dans le meme espace de nommage que son second parametre, il est pris en 
compte lors de la resolution de l'appel std: : accumulate o en vertu de la regie de 
Koenig, qui, rappelons-le, specifie que le compilateur doit prendre en compte les espa- 
ces de nommage dans lesquels sont declares les types des parametres d'une fonction 
lors de la resolution de 1' appel de cette fonction. Ainsi, le compilateur trouve imme- 
diatement le bon operatort ( ) , evitant les problemes de l'exemple 2 initial. 

II etait pre visible que l'exemple 2 n'allait pas fonctionner, car il ne se conformait 
pas au Principe d'interface : 

L'interface d'une classe x est constitute de toutes les fonctions, membres 
ou globales, qui « font reference a x » et « sont fournies avec x » 

Si une fonction globale (et, a plus forte raison, un operateur) fait reference a une 
classe et est conceptuellement concu pour « faire partie » de cette classe, alors il faut 
le « fournir avec » la classe, c'est-a-dire, entre autres choses, la declarer dans le meme 
espace de nommage que la classe. Tous les ennuis rencontres dans l'exemple 2 prove- 
naient du fait que la fonction operatort ( ) , rattachee conceptuellement a la classe c, 
etait situee dans un espace de nommage different de celui ou est declaree cette classe. 

En conclusion, arrangez-vous pour toujours placer une classe et toutes les fonc- 
tions globales qui lui sont rattachees dans le meme espace de nommage - lequel peut 
etre l'espace de nommage global : ceci vous evitera de tomber sur des erreurs parfois 
subfiles liees a l'algorifhme de resolution de noms. 



Recommandation 

Soyez prudents lorsque vous utilisez des espaces de nommage. Si vous placez une classe 
dans un espace de nommage, placez-y egalement toutes les fonctions globales rattachees a la 
classe; ceci vous evitera bien de mauvaises surprises. 
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Pb n° 35. Gestion de la memoire 

(1 re partie) Difficulte : 3 



MaTtrisez-vous bien les differentes zones memoires et leur utilite ? Ce probleme va etre I'occa- 
sionde tester vos connaissances. 



Le C++ utilise plusieurs zones memoires, ayant chacune des caracteristiques diffe- 
rentes. 

Enumerez toutes les zones memoires que vous connaissez, en precisant pour cha- 
cune les types de variables pouvant y etre stockes - types predefinis et/ou objets - 
ainsi que la duree de vie des ces variables (par exemple, la pile contient des variables 
automatiques, qui peuvent etre des objets ou des variables de type predefini). 

Vous indiquerez egalement les performances relatives de ces differentes zones. 

f SoLUT,ON 

Le tableau ci-dessous recense les differentes zones memoires utilisees par le C++. 
Notez bien la difference entre le tas (heap) et la memoire globale (free store), qui sont 
deux zones bien distinctes, contenant chacune un certain type de variables allouees 
dynamiquement. 

En tant que programmeur, il est important de bien differencier le tas de la memoire 
globale, la norme C++ laissant deliberement la possibilite de les differencier ou non 
dans 1' implementation du compilateur. 
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Table 1 : Zones memoires utilisees par le C++ 



Zone memoire Caracteristiques - Duree de vie des variables contenues 



Donnees La zone « Donnees constantes » contient toutes les variables constantes - autrement dit 
constantes celles dont la valeur est connue a la compilation. Cette zone ne peut pas contenir d'objets. 

Les variables contenues sont crees lors du demarrage du programme et detruites a la fin de 
l'execution. Ces variables sont en lecture seule (toute tentative de modification de l'une 
d'entre elles conduit a un resultat indetermine, dependant des optimisations mises en oeu- 
vre par le compilateur) 

Pile (stack) La pile contient des variables automatiques (objets ou variables de types predefinis), qui 
sont allouees au debut du bloc dans lequel elles sont definies et detruites a la fin de ce bloc. 
Les objets sont construits immediatement apres leur allocation et detruits immediatement 
avant leur desallocation. Autrement dit, le programmeur n'a aucun moyen de manipuler 
des variables de la pile allouees mais non initialisees (a moins d'utiliser une destruction 
explicite suivi d'une reallocation forcee a une adresse donnee, pratique peu recommand- 
able). Les allocations memoires dans la pile sont nettement plus rapides que les allocations 
dynamiques dans le tas ou la memoire globale (decrits plus bas), etant donne qu'il suffit de 
decaler un pointeur, au lieu d'operer une recherche d'emplacement libre, plus complexe. 

Memoire La memoire globale contient les variables et tableaux alloues par l'operateur new (et desal- 
globale loues par delete). C'est l'une des deux zones d' allocation dynamique. Dans cette zone, la 

(free store) duree de vie d'un objet peut etre inferieure a la duree d'allocation de la memoire qui lui est 
associee : en effet, il peut arriver qu'un objet soit alloue sans etre immediatement construit 
et detruit sans etre immediatement desalloue. Durant la periode oil un objet est alloue mais 
inexistant (i.e. pas encore construit ou deja detruit), la memoire associee a cet objet peut 
etre manipulee par l'intermediaire d'un pointeur de type void* . Neanmoins, aucun des 
membres de l'objet (variable ou fonction) ne peut etre manipule. 

Tas (heap) Le tas est l'autre zone utilisee pour l'allocation dynamique. Elle contient les variables et 
tableaux alloues avec malloc ( ) (et liberes avec free ( ) ). Le tas et la memoire globale 
sont deux emplacements bien distincts : le resultat de la desallocation par free ( ) de vari- 
ables ou tableaux alloues par new - et vice versa - est imprevisible, bien que cela fonc- 
tionne avec les compilateurs pour lesquels new et delete sont implementes en fonction de 
malloc ( ) et free ( ) , ce qui n'est pas le cas de tous. Une zone de memoire allouee dans le 
tas peut etre utilisee pour stacker un objet, a condition d'appliquer l'operateur new en 
forcant l'adresse d'allocation (et d'effectuer une destruction explicite lors de la fin de l'util- 
isation de l'objet). Dans le cas d'une utilisation de ce type, les notes relatives a la duree de 
vie des objets dans la memoire globale s'appliquent. 

Variables Les variables globales et statiques sont allouees au demarrage du programme. Neanmoins, 
globales et contrairement aux variables constantes, elles peuvent n'etre initialisees que plus tard, au 
statiques cours de l'execution du programme : par exemple, une variable statique definie au sein 
d'une fonction n'est initialisee que lors de la premiere execution de la fonction. L'ordre 
d' initialisation des differentes variables globales et statiques des differents modules (y 
compris les membres statiques de classes) n'est pas defini : il est done dangereux de faire 
l'hypothese que telle variable s'initialisera avant telle autre. La encore, les zones memoires 
des objets alloues mais non initialises peuvent etre manipulees par l'intermediaire d'un 
pointeur de type void*, mais aucun des membres de l'objet ne peut etre manipule (qu'il 
s'agisse d'une variable ou d'une fonction). 
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Ainsi, la section 18.4.1.1 de la norme C++ precise les points suivants : 

^implementation des operateurs new et new [ ] par le compilateur est libre. 
En particulier, ces operateurs sont libres de faire appel ou non aux fonc- 
tions C classiques caiioco, maiioco et reaiioco declarees dans 

<cstdlib>. 

De plus, la norme C++ ne specifie pas si new et delete doivent faire appel a mai- 
loc o et free o dans leur implementation, bien qu'a contrario, il soit explicitement 
indique (20.4.6 §3 et 4) que maiioc o et free one doivent pas faire appel a new et 
delete dans leur implementation : 

Les fonctions caiioc ( ) , maiioc ( ) et reaiioc ( ) ne doivent pas faire appel 
a I'operateur ■. ■. new dans leur implementation 

La fonction free ( ) ne doit pas faire appel a I'operateur ■. ■. delete dans son 
implementation. 

En pratique, le tas et la memoire globale se comportent differemment : dans vos 
programmes, assurez-vous de ne pas les traiter comme une unique et meme zone. 



Recommandations 

Retenez le fonction nement des cinq zones memoires utilisees par le C++ : pile (variables 
automatiques), memoire globale (new/delete), tas (maiioc / free), variables globales/stati- 
ques et donnees constantes. 

Utilisez new et delete plutot que maiioc et free. 



Pb n° 36. Gestion de la memoire (2 e partie) Difficulte : 3 



Ce probleme aborde differentes questions relatives a la redefinition des operateurs new/delete 

et new [ ] /delete [ ] . 

Le code ci-dessous contient des exemples de classes effectuant elles-memes la 
gestion de leur propre allocation/desallocation. Examinez-le et identifiez les erreurs 
qu'il contient. Repondez egalement aux questions additionnelles. 

1 . Considerez le code suivant : 

class B 
{ 

public : 

virtual ~B ( ) ; 

void operator delete ( void*, size_t ) throw (); 
void operator delete [] ( void*, size_t ) throw (); 
void f( void*, size_t ) throw (); 

}; 
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class D : public B 
{ 

public : 

void operator delete ( void* ) throw (); 
void operator delete [] ( void* ) throw (); 

>; 

Pourquoi les operateurs delete de b ont-ils deux parametres, alors que ceux de d 
n'en ont qu'un ? 

Est-il possible d' ameliorer les declarations des fonctions ? 

2. Examinez maintenant le code suivant, utilisant les classes b et d definies plus haut. 
Indiquez, pour chacune des operations de destruction, lequel des operateurs delete 
est appele (et avec quels parametres). 

D* pdl = new D; 

delete pdl; 

B* pbl = new D; 

delete pbl; 

D* pd2 = new D [10] ; 

delete[] pd2; 

B* pb2 = new D [10] ; 

delete [ ] pb2 ; 

3. Les affectations suivantes sont-elles correctes ? 

B b; 

typedef void (B::*PMF) (void*, size_t); 

PMF pi = SB: : f ; 

PMF p2 = &B::operator delete; 

Le code suivant est-il susceptible de poser des problemes de gestion de memoire ? 

class X 
{ 

public : 

void* operator new ( size_t s, int ) 
throw ( bad_alloc ) 

{ 

return :: operator new ( s ); 

} 

>; 

class SharedMemory 
{ 

public : 

static void* Allocate ( size_t s ) 
{ 

return OsSpecif icSharedMemAllocation ( s ) ; 

} 

static void Deallocate ( void* p, int i ) 
{ 

OsSpecif icSharedMemDeallocation ( p, i ) ; 

} 

}; 
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class Y 
{ 

public : 

void* operator new ( size_t s, 

SharedMemory & m ) throw ( bad_alloc ) 

{ 

return m. Allocate) s ); 

} 

void operator delete ( void* p, 

SharedMemory & m, 
int i ) throw () 

{ 

m . Deallocate ( p, i ) ; 

} 

void operator delete ( void* p ) throw () 

SharedMemory :: Deallocate ( p ); 
void operator delete ( void* p, std: : nothrowJS ) throw () 

SharedMemory :: Deallocate ( p ); 



1 . Considerez le code suivant : 

class B 
{ 

public : 

virtual ~B ( ) ; 

void operator delete ( void*, size_t ) throw () ; 
void operator delete[]( void*, size_t ) throw () ; 
void f( void*, size_t ) throw() ; 

}; 

class D : public B 
{ 

public : 

void operator delete ( void* ) throw (); 
void operator delete []( void* ) throw (); 

}; 

Pourquoi les operateurs delete de b ont-ils deux parametres, alors que ceux de d 
n'en ont qu'un ? 

II n'y a pas d' autre reponse a cette question que « parce que le programmeur en a 
decide ainsi ». En effet, les deux formes sont equivalentes et tout a fait valables (pour 
plus d' informations, se reporter a la norme C++ §3.7.3.2/3). 

En revanche, il est a noter un defaut majeur dans 1' implementation des classes b et 
d : les operateurs delete et delete [ ] ont ete redefinis sans que les operateurs new et 
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new [ ] ne le soient egalement. C'est tres dangereux, car rien n'indique que les opera- 
teurs new et new [ ] par defaut, qui seront done utilises, effectuent des operations syme- 
triques de celles implementees dans les operateurs delete et delete [ ] de b et d. 



Recommandation 

Si vous redefinissez des operateurs de gestion memoire pour une classe, n'implementez 
jamais I'operateur new (ou new[]) sans implementer I'operateur delete (ou delete []), et 
vice-versa. 



Est-il possible d' ameliorer les declarations des fonctions ? 

Les operateurs new et delete (ou new [ ] et delete [ ] ) sont toujours considered par 
le compilateur comme des fonctions statiques, meme lorsqu'elles ne sont pas explici- 
tement declarees static. II est recommande de qualifier systematiquement ces opera- 
teurs avec le mot-cle static, bien que ce ne soit pas exige par le compilateur, afin de 
faciliter la maintenance du code. 



Recommandation 

Declarez toujours explicitement les operateurs new (newn) et delete (delete []) 
comme des fonctions statiques, nonobstant le fait que, si le mot-cle static est omis, les fonc- 
tions seront tout de meme considerees comme statiques par le compilateur. 



2. lndiquez, pour chacune des operations de destruction, lequel des operateurs 
delete est appele (et avec quels parametres). 

D* pdl = new D; 
delete pdl; 

C'est la fonction d : : operator delete ( void* ) qui est appelee 

B* pdl = new D; 
delete pdl; 

C'est encore la fonction d : : operator delete ( void* ) qui est appelee. En effet, le 
fait que le destructeur de b soit virtuel implique non seulement que le destructeur de d 
sera appele, mais egalement que I'operateur d —operator delete (void* )le sera, 
bien que la fonction b —operator delete (void*) n' est pas (et d'ailleurs, ne peut 
pas etre) virtuelle. 

Pour mieux comprendre ce dernier point, il faut savoir qu'en general, les compilateurs 
implementent un destructeur comme une fonction recevant une variable booleenne signi- 
fiant « lorsque j'aurai detruit l'objet, devrai-je le desallouer ? », qui est positionnee a 
false dans le cas d'un objet automatique et a true dans le cas d'un objet alloue dynami- 
quement. La derniere operation que fait le destructeur est de tester la valeur de cette varia- 
ble et, si elle vaut true, d'appeler I'operateur delete de l'objet venant d'etre detruit 1 . 



1. L' implementation correspondante dans le cas d'un tableau est laissee aux bons soins du 
lecteur, a titre d'exercice. 
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C'est ainsi que l'operateur delete donne l'impression de se comporter comme une fonc- 
tion virtuelle alors que, dans les faits, il n'est pas virtuel (et ne peut pas l'etre, puis qu'il 
est statique). 

D* pd2 = new D [10] ; 
delete pd2; 

Appelle l'operateur D: : operator delete[] (void*) 

B* pd2 = new D [10] ; 
delete pd2; 

Le resultat que produit ce code est indetermine. En effet, la norme C++ impose 
que le type du pointeur passe a une fonction operator delete [ ] soit le meme que le 
type des objets vers lesquelles pointent ce pointeur. Pour plus d' informations sur ce 
sujet, voir Meyers99 : « Never Treat Arrays Polymorphically » 

Recommandation 

Ne considerez pas les tableaux comme des types polymorphiques. 



3. Les affectations suivantes sont-elles correctes ? 

B b; 

typedef void (B::*PMF) (void*, size_t); 

PMF pi = SB: : f ; 

PMF p2 = SB : : operator delete ; 

La premiere affectation est correcte : nous affectons a un pointeur vers une fonc- 
tion membre l'adresse d'une fonction membre ay ant la bonne signature. 

La seconde affectation est incorrecte : en effet, la fonction operator: : delete 
n'est pas une fonction membre statique. Signalons encore une fois que les operateurs 
new et delete sont obligatoirement des fonctions membres statiques, meme si elles ne 
sont pas explicitement declarees static dans le programme. Nous rappelons qu'il est 
recommande de qualifier systematiquement ces operateurs avec le mot-cle static, 
arm de faciliter la lisibilite et la maintenance du code. 



Recommandation 

Declarez toujours explicitement les operateurs new (new [ ] ) et delete (delete [ ] ) comme 
des fonctions statiques, nonobstant le fait que, si le mot-cle static est omis, les fonctions 
seront tout de meme considerees comme statiques par le compilateur. 



4. Le code suivant est-il susceptible de poser des problemes de gestion de memoire ? 
Reponse courte : oui. Detaillons maintenant chacun des cas proposes : 
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class X 
{ 

public : 

void* operator new( size_t s, int ) throw ( bad_alloc ) 
{ 

return :: operator new ( s ); 



Cette classe est susceptible de provoquer des fuites memoires, car Foperateur new a 
ete redefini sans que Foperateur delete correspondant ne Fait ete egalement. 

Le meme probleme se pose pour la classe ci-dessous : 

class SharedMemory 
{ 

public : 

static void* Allocate ( size_t s ) 
{ 

return OsSpecif icSharedMemAllocation ( s ); 

} 

static void Deallocate ( void* p, int i ) 
{ 

OsSpecif icSharedMemDeallocation ( p, i ) ; 



class Y 
{ 

public : 

void* operator new( size_t s, SharedMemoryS m ) 

throw ( bad_alloc ) 

{ 

return m. Allocate) s ); 

} 

Cette classe peut generer des fuites memoires, car aucun operateur delete corres- 
pondant a la signature de cet operateur new n'a ete redefini. Si une exception se pro- 
duisait au cours de la construction d'un objet alloue par cette fonction, le memoire ne 
serait pas correctement liberee car aucun operateur delete ne serait appele. 

Le code suivant, par exemple, pose probleme : 

SharedMemory shared ; 
new (shared) Y ; 

// Si Y: :Y() lance une exception, la memoire ne sera pas liberee. 

Tout objet alloue par cet operateur new ( ) ne pourra jamais etre detruit proprement, 
car la classe y n'implemente pas d'operateur delete classique. 

void operator delete ( void* p, 

SharedMemoryS m, 
int i ) throw () 
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m . Deallocate ( p, i ) ; 

} 

}; 

Cette fonction Y: : operator delete o est inutile car elle ne pourra jamais etre 
appelee. 

void operator delete ( void* p ) throw ( ) 
{ 

SharedMemory: : Deallocate ( p ); 

} 

Ce code risque de provoquer des erreurs graves a l'execution, etant donne qu'il va 
desallouer avec la fonction Deallocate ( ) de la memoire ayant ete allouee par l'opera- 

teur new. 

void operator delete ( void* p, std: :nothrow_t&) throw () 
{ 

SharedMemory :: Deallocate ( p ); 

} 

Merae remarque ici, bien que la situation d'erreur soit un peu subtile : un pro- 
bleme se produira si un appel a « new (nothrow) t » echoue sur une exception emise 
par le constructeur de t, ce qui provoquera, la encore, la deallocation d'un espace 

memoire non alloue par SharedMemory: : Allocate () . 



Recommandation 

Si vous redefinissez des operateurs de gestion memoire pour une classe, n'implementez 
jamais I'operateur new (ou new[]) sans implementer I'operateur delete (ou delete []), et 
vice-versa. 



Pb n° 37. auto ptr 



Difficulte : 8 



Ce probleme aborde le fonctionnement et I'utilisation du pointeur intelligent auto_ptr, de la 
bibliotheque standard C++. 



Avant tout, commencons par un bref historique de ce sujet. Ce probleme est initia- 
lement paru sous une forme plus simple que celle presentee ici, dans une edition spe- 
ciale de Guru of the Week parue a l'occasion de l'adoption du Final Draft 
International Standard for Programming Language C++. Cette parution tardive - 
survenue la veille meme du debut du comite de normalisation - ayant souleve des 
questions importantes, tout le monde se doutait que la fonctionnalite auto_ptr allait 
subir des modifications lors du comite final d' adoption de la norme. Lorsque celui-ci 
eut lieu (a Morristown, New Jersey en novembre 97), il prit effectivement en compte 
les ameliorations proposees suite a la parution du probleme en question. 
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C'est ici l'occasion de remercier tous ceux qui ont participe a la finalisation du 
chapitre auto_ptr de la norme C++, notamment Bill Gibbons, Steve Rumbay et sur- 
tout Greg Collins, qui a travaille longuement sur les « pointeurs intelligents » en gene- 
ral, dans le but de les adapter aux differentes contraintes imposees par les nombreux 
comites de normalisation. 

Nous presentons ici une solution complete et detaillee du probleme original, qui 
illustre notamment la raison pour laquelle des changements de derniere minute ont ete 
apportes a la norme et indique la meilleure maniere d'utiliser auto_ptr. 

Examinez le code suivant. Indiquez quelles instructions vous semblent correctes 
ou incorrectes. 

auto_ptr<T> source () 
{ 

return auto_ptr<T> ( new T(l) ) ; 

} 

void sink ( auto_ptr<T> pt ) { } 

void f() 

{ 

auto_ptr<T> a( source () ); 
sink ( source ( ) ) ; 

sink( auto_ptr<T> ( new T(l) ) ); 
vector< auto_ptr<T> > v; 

v.push_back( auto_ptr<T> ( new T(3) ) ); 
v.push_back( auto_ptr<T> ( new T(4) ) ); 
v.push_back( auto_ptr<T> ( new T(l) ) ); 
v.push_back( a ); 

v.push_back( auto_ptr<T> ( new T(2) ) ); 
sort ( v.begin{), v.endO ); 

cout << a->Value(); 

} 

class C 
{ 

public : /*...*/ 
protected: /*...*/ 
private : 

auto_ptr<CImpl> pimpl_; 

}; 



Solution 

Nombreux sont ceux qui ont entendu parler du « pointeur intelligent » auto_ptr, 
mais rares sont ceux qui Futilisent quotidiennement. C'est a deplorer, car auto_ptr 
facilite grandement l'ecriture du code et, plus encore, contribue a rendre les program- 
mes plus robustes. Cette section expose les divers avantages d'auto_ptr et met egale- 
ment en avant certains modes d' utilisations dangereux des « pointeurs intelligents », 
qui peuvent parfois conduire a des bogues difficiles a diagnostiquer. 
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A quoi sert auto_ptr ? 

auto_ptr n'est qu'un exemple de « pointeur intelligent » parmi d'autres. De nom- 
breuses bibliofheques du marche fournissent des pointeurs intelligents plus sophisti- 
ques, dotes de fonctionnalites variees allant du compteur de reference jusqu'a des 
services de type « proxy » qu'on rencontre dans les gestionnaires d'objets distribues. 

auto_ptr n'est qu'un type tres simple de pointeur intelligent, mais il procure 
neanmoins d'indeniables avantages dans la programmation au quotidien : auto_ptr 
est un pointeur rattache a un objet alloue dynamiquement, qui desalloue automatique- 
ment cet objet lorsqu'il n'est plus utilise. 

// Exemple 1 (a) : Code original 

// 

void f() 
{ 

T* pt ( new T ) ; 

/* */ 

delete pt; 

} 

La majorite d'entre nous ecrit, chaque jour, du code ressemblant a celui-ci. Si la 
fonction f ( ) ne comporte que quelques lignes, ca ne pose generalement pas de pro- 
bleme. Mais si to est plus complexe et que les chemins d' execution possibles sont 
plus difficiles a controler ou qu'une exception est susceptible d'etre generee au cours 
de l'execution de la fonction, il y a un risque plus important que l'appel a delete ne 
soit pas effectue lorsque le programme quitte la fonction, autrement dit un risque de 
fuite memoire (objet alloue mais non detruit). 

Une maniere simple de rendre l'exemple 1(a) plus sur est d'encapsuler le pointeur 
original dans un pointeur intelligent, dont la fonction sera de detruire automatique- 
ment l'objet alloue lors de la fin de l'execution de la fonction. Ce pointeur intelligent 
etant une variable automatique (automatiquement detruit a la fin du bloc a l'interieur 
duquel il est declare), il est naturel de le qualifier de auto_ptr. 

// Exemple 1 (b) : Code securise grace a auto_ptr 

// 

void f() 
{ 

auto_ptr<T> pt ( new T ) ; 

/* */ 

} 

// Lorsque la fonction se termine, le destructeur de pt est 
// appele et l'objet associe est automatiquement detruit 

Dans l'exemple ci-dessus, nous sommes assures de la deallocation correcte de T, 
quelle que soit la maniere dont se termine la fonction to - fin normale ou exception - 
car le destructeur de pt sera automatiquement appele lors de la deallocation des varia- 
bles de la pile. 

Pour reprendre le controle d'un objet rattache a un auto_ptr, il suffit d'appeler 
release ( ) - l'utilisateur reprend alors la responsabilite de la destruction de l'objet. 
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// Exemple 2: Utilisation d' auto_ptr 

// 

void g ( ) 
{ 

T* ptl = new T; 

// On passe le controle de l'objet alloue a ptl 
auto_ptr<T> pt2 ( ptl ); 

// On utilise pt2 comme on le ferait avec un pointeur normal 
*pt2 = 12; // equivalent a "*ptl = 12;" 

pt2->SomeFunc ( ) ; // equivalent "ptl->SomeFunc ( ) ; " 
// La fonction get() fournit la valeur du pointeur 
assert ( ptl == pt2.get() ); 

// La fonction release)) permet de reprendre le controle 
T* pt3 = pt2 . release () ; 

// Nous devons detruire l'objet manuellement , 
// car il n'est plus controle par l'auto_ptr 
delete pt3; 

) // pt2 ne controle plus aucun objet, et ne va done pas 
// essayer de desallouer quoi que ce soit . 

On peut egalement utiliser la fonction reset ( ) membre d'auto_ptr pour ratta- 
cher un nouvel objet a un auto_ptr existant. Si l'auto_ptr est deja rattache a un 
objet, il detruira d'abord ce premier objet (autrement dit, appliquer reset o a un 
auto_ptr est equivalent a detruire ce pointeur et a en creer un nouveau pointant vers 
le nouvel objet). 

// Exemple 3: Utilisation de reset () 

// 

void h ( ) 
{ 

auto_ptr<T> pt ( new T(l) ); 
pt. reset ( new T(2) ); 

// Detruit le premier objet T, 

// qui avait ete alloue par "new T(l)" 
) // A la fin de la fonction, pt est detruit, 
// et par consequent, le second T l'est aussi 

Encapsulation de variables membres de type 
pointeur 

De maniere similaire, auto_ptr peut etre utilise pour encapsuler une variable 
membre de type pointeur, comme le montre 1' exemple suivant, qui utilise un 
« Pimpl 1 » (pare-feu logiciel). 



1. Le principe du « Pimpl », ou pare-feu logiciel, est couramment utilise pour reduire le 
temps de recompilation des projets en faisant en sorte que le code client d'une classe ne 
soit pas recompile lorsque la partie privee de cette classe est modifiee. Pour plus 
d' informations sur ce sujet, se reporter aux problemes 26 a 30. 
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// Exemple 

// 

// Fichier 

// 

class C 



c.h 



4 (a) : un exemple de "Pimpl 



public : 

CO; 

-CO; 

/*...*/ 
private : 

class Clmpl; // declaration differee 
Clmpl* pimpl_; 



// Fichier c . cpp 

// 

class C : : Clmpl { /*...*/ } ; 
C::C() : pimpl_( new Clmpl ) { } 
C::~C() { delete pimpl_; } 

Dans cet exemple, la partie privee de c est implementee dans une classe secondaire 
cimpi, dont une instance est allouee dynamiquement lors de la construction de c et 
desallouee lors de sa destruction. La classe c contient une variable membre de type 
cimpi* pour conserver l'adresse de cette instance. 

Voici comme cet exemple peut etre simplifie grace a 1' utilisation d'auto_ptr : 

// Exemple 4 (b) : "Pimpl" utilisant auto_ptr 
// 

// Fichier c.h 

// 

class C 
{ 

public : 

CO; 

~C ( ) ; 

/*...*/ 
private : 

class Clmpl; // declaration differee 

auto_ptr<CImpl> pimpl_; 

CS operator = ( const C& ) ; 

C ( const C& ) ; 



// Fichier c . cpp 

// 

class C: : Clmpl { /*...*/ }; 
C::C() : pimpl_( new Clmpl ) { } 
C::~C() {} 

A present, il n'est plus necessaire de detruire explicitement pimpi_ dans le des- 
tructeur de C : l'auto_ptr s'en chargera automatiquement. Mieux encore, la classe c 
n' a plus a se soucier de la detection et du traitement des eventuelles exceptions pou- 
vant se produire dans 1' execution de son constructeur c : :C()car, contrairement a 
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l'exemple precedent, le pointeur pimpi_ est automatiquement desalloue en cas de pro- 
bleme de ce type. Cette solution s'avere finalement plus securisee et plus simple que 
la gestion manuelle du pointeur. D'une maniere generale, la pratique consistant a dele- 
guer la gestion d'une ressource a un objet est recommandee - c'est ce que nous fai- 
sons ici avec auto_ptr gerant l'objet prive pimpi_. Nous reviendrons sur cet 
exemple a la fin du chapitre. 

Appartenance, sources et puits 

Nous avons deja un premier apercu des possibilites offertes par auto_ptr, mais 
nous n'en sommes qu'au debut : voyons maintenant a quel point il est pratique d'uti- 
liser des auto_ptr lors d'appels de fonctions, qu'il s'agisse d'en passer en parametre 
ou bien d'en recevoir en valeur de retour. 

Pour cela, interessons-nous en premier lieu a ce qui se passe lorsqu'on copie un 
auto_ptr : l'operation de copie d'un auto_ptr source, pointant vers un objet donne, 
vers un auto_ptr cible, a pour effet de transferer l'appartenance de l'objet pointe du 
pointeur source au pointeur cible. Le principe sous-jacent est qu'un objet pointe ne 
peut appartenir qu'a un seul auto_ptr a la fois. Si l'auto_ptr cible pointait deja vers 
un objet, cet objet est desalloue au moment de la copie. Une fois la copie effectuee, 
l'objet initial appartiendra done a l'auto_ptr cible, tandis que Pauto_ptr source sera 
reinitialise et ne pourra plus etre utilise pour faire reference a cet objet. C'est 
Pauto_ptr cible qui, le moment venu, detruira l'objet initial : 

// Exemple 5: Transfert d'un objet 

// d'un auto_ptr a un autre 

// 

void f() 
{ 

auto_ptr<T> ptl ( new T ); 
auto_ptr<T> pt2; 
ptl->DoSomething ( ) ; // OK 

pt2 = ptl; // Maintenant, c'est pt2 qui controle 

// l'objet T 
pt2->DoSomething ( ) ; // OK 
) // Lorsque la fonction se termine, le destructeur 
// de pt2 detruit l'objet; ptl ne fait rien 

Faites bien attention de ne pas utiliser un auto_ptr auquel plus aucun objet 
n'appartient : 

// Exemple 6: Utilisation d'un auto_ptr ne controlant rien 
// A NE PAS FAIRE ! 

// 

void f() 
{ 

auto_ptr<T> ptl ( new T ); 
auto_ptr<T> pt2; 

pt2 = ptl; // Maintenant, pt2 controle l'objet alloue 
// ptl ne controle plus aucun objet. 
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pt l->Do Some thing ( ) ; 

// Erreur : utilisation d'un pointeur nul ! 

} 

Voyons maintenant a quel point auto_ptr est bien adapte a 1' implementation de 
sources et de puits. Une « source » est une fonction qui cree un nouvel objet puis 
abandonne le controle de cet objet a 1' appelant. Un « puits » est une fonction qui, a 
l'inverse, prend le controle d'un objet existant (et generalement, detruit cet objet apres 
1' avoir utilise). 

Dans 1' implementation de sources et de puits, plutot que d'utiliser de simples 
pointeurs pointant vers l'objet manipule, il peut s'averer tres pratique de renvoyer 
(resp. prendre en parametre) un pointeur intelligent rattache a cet objet. 

Ceci nous amene finalement aux premieres lignes de code de l'enonce de notre 
probleme : 

auto_ptr<T> source () 
{ 

return auto_ptr<T> ( new T(l) ); 

} 

void sink ( auto_ptr<T> pt ) { } 

Non seulement ces lignes sont tout a fait correctes, mais, de plus, elles sont tres 
elegantes : 

1 . La maniere avec laquelle la fonction source ( ) cree un nouvel objet et le renvoie a 
l'appelant est parfaitement securisee : l'auto_ptr assure que l'objet alloue sera 
detruit en temps voulu. Merae si, par erreur, l'appelant ignore la valeur de retour 
de la fonction, l'objet sera egalement correctement detruit. Voir egalement le pro- 
bleme n° 19, qui demontre que la technique consistant a encapsuler la valeur 
retournee par une fonction dans un auto_ptr - ou un objet equivalent - est le seul 
moyen de vraiment s'assurer que cette fonction se comportera correctement en 
presence d' exceptions. 

2. Lorsqu'elle est appelee, la fonction sink o prend le controle du pointeur qui lui 
est passe en parametre car celui-ci est encapsule dans un auto_ptr, ce qui assure 
la destruction de l'objet associe lorsque la fonction se termine (a moins que 
sinko n'ait, au cours de son execution, transmis le controle du pointeur a une 
autre fonction). On peut noter que, dans notre exemple, la fonction sinko est 
equivalente a pt . reset ( 0 ) , dans la mesure ou elle n'effectue aucune operation. 

La suite du code montre un exemple d'utilisation de source ( ) et sink ( ) : 

void f() 
{ 

auto_ptr<T> a( source () ); 

Instruction tout a fait correcte et sans danger : la fonction f ( ) prend le controle de 
l'objet alloue par source o , l'auto_ptr assurant qu'il sera automatiquement detruit 
lors de la fin de l'execution de f ( ) , qu'il s'agisse d'une fin normale ou d'une fin pre- 
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maturee suite a une exception. C'est un exemple tout a fait classique de 1' utilisation 
d'auto_ptr comme valeur de retour d'une fonction. 

sink ( source ( ) ) ; 

La encore, instruction correcte et sans danger. Etant donne 1' implementation mini- 
male de source ( ) et sink ( ) , ce code est equivalent a « delete new t (i) ». S'il est 
vrai que l'avantage procure par auto_ptr n'est pas flagrant dans notre exemple, soyez 
convaincus que lorsque source ( ) et sink ( ) sont des fonctions complexes, Futilisation 
d'un pointeur intelligent presente alors un interet certain. 

sink( auto_ptr<T>( new T(l) ) ) ; 

Toujours correct et sans danger. Une nouvelle maniere d'ecrire « delete new 
t (i) » mais, encore une fois, une technique interessante lorsque sink o est une fonc- 
tion complexe qui prend le controle de l'objet alloue. 

Nous avons presente ici les emplois classiques d'auto_ptr. Attention ! Mefiez- 
vous des utilisations qui different de celles exposees plus haut : auto_ptr n'est pas un 
objet comme les autres ! Certains emplois non controles peuvent causer des proble- 
mes, en particulier : 

La copie d'un auto_ptr ne realise pas de copie de l'objet pointe. 

Ceci a pour consequence qu'il est dangereux d'utiliser des auto_ptr dans un pro- 
gramme effectuant des copies en supposant implicitement - ce qui est generalement le 
cas - que les operations de copie effectuent un clonage de l'objet copie. 

Considerez par exemple le code suivant, regulierement rencontre dans les groupes 
de discussions C++ sur l'lnternet : 

vector< auto_ptr<T> > v; 

Cette instruction est incorrecte et presente des dangers ! D'une maniere generate, il est 
toujours dangereux d'utiliser des auto_ptrs avec des conteneurs standards. Certains vous 
diront qu'avec leur compilateur et leur version de la bibliotheque standard, ce code fonc- 
tionne correctement, d' autres soutiendront que l'instruction ci-dessous est precisement 
citee a titre d' exemple dans la documentation d'un compilateur populaire : tous ont tort ! 
Le fait qu'une operation de copie entre auto_ptrs transmette le controle de l'objet pointe a 
l'auto_ptr cible au lieu de realiser une copie de cet objet rend tres dangereux l'utilisation 
des auto_ptr avec les conteneurs standards ! II suffit, par exemple, qu'une implantation de 
vector ( ) effectue une copie interne d'un des auto_ptr stocke pour que l'utilisateur vou- 
lant obtenir ulterieurement cet auto_ptr recupere un objet contenant un pointeur nul. 

Ce n'est pas tout, il y a pire : 

v.push_back( auto_ptr<T> ( new T(3) ) ); 
v.push_back( auto_ptr<T> ( new T(4) ) ); 
v.push_back( auto_ptr<T> ( new T(l) ) ); 
v.push_back( a ); 

(Notez ici que le fait de la passer par valeur a pour effet d' oter a la variable a le controle 
de l'objet vers lequel elle pointe. Nous reviendrons sur ce point ulterieurement.) 
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v.push_back( auto_ptr<T> ( new T(2) ) ); 
sort ( v.begin(), v . end ( ] ); 

Ce code est incorrect et dangereux. La fonction sortoainsi d'ailleurs que 
1' ensemble des fonctions de la bibliotheque standard qui effectuent des copies fait 
l'hypofhese que ces copies laissent inchange l'objet source de la copie. S'il y a plu- 
sieurs implementations possible de sorto, l'une des plus courantes a recours, en 
interne, a un element « pivot » destine a contenir des copies des certains des objets a 
trier. Voyons ce qui se passe lorsqu'on trie des auto_ptrs : lorsqu'un element est 
copie dans 1' element pivot, le controle de l'objet pointe par cet auto_ptr est transmis 
a l'auto_ptr pivot, qui est malheureusement temporaire. Lorsque le tri sera termine, 
le pivot sera detruit et c'est la que se posera le probleme : un des objets de la sequence 
originale sera detruit ! 

C'est pour eviter ce genre de problemes que le comite de normalisation C++ a 
decide de proceder a des modifications de derniere minute : l'auto_ptr a ete specifi- 
quement concu pour provoquer une erreur de compilation lorsqu'il est utilise avec un 
conteneur standard - regie qui a ete mise en place, en pratique, dans la grande majo- 
rity des implementations de la bibliotheque standard. Pour cela, le comite a specifie 
que les fonctions insert o de chaque conteneur standard devaient prendre en para- 
metre des references constantes, interdisant par la meme leur emploi avec les 
auto_ptr, pour lesquels le constructeur de copie et l'operateur d' affectation prennent 
en parametres des references non constantes. 

Cas des auto_ptr ne controlant aucun objet 

// (apres la copie de a vers un autre auto_ptr) 
cout << a->Value(); 

} 

Meme si, avec un peu de chance l'objet pointe peut, en depit de la copie de a, ne 
pas avoir ete detruit par l'objet vector ou la fonction sort ( ) , ce code posera de toute 
maniere un probleme, car la copie d'un auto_ptr provoque non seulement le trans- 
fert de l'objet pointe vers l'auto_ptr cible, mais encore positionne a NULL la valeur 
de l'auto_ptr source. Ceci est fait specifiquement dans le but d'eviter l'utilisation 
d'un auto_ptr ne controlant aucun objet. Le code ci-dessus provoquera done imman- 
quablement une erreur a Fexecution. 

Voyons pour finir le dernier des usages courants d'auto_ptr 

Encapsulation de pointeurs membres 

Les auto_ptrs peuvent etre utilises pour encapsuler des variables membres de 
type pointeur : 

class C 
{ 

public : /*...*/ 
protected: /*...*/ 
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private : 

auto_ptr<CImpl> pimpl_; 

}; 

Ainsi, de maniere analogue a leur utilisation au sein de fonctions, ils evitent au 
developpeur d' avoir a se soucier de la destruction de l'objet alloue, laquelle a ici lieu 
automatiquement lors de la destruction de c. 

II subsiste une contrainte - analogue a celle qu'on rencontrerait dans le cas de 
Futilisation de pointeurs simples : il est obligatoire de redefinir vos propres 
constructeur de copie et operateur d' affectation pour la classe c (ou, au pire, d'inter- 
dire la copie et 1' affectation en les declarant private sans les implemented), car les 
fonctions fournies par defaut par le compilateur poseraient probleme. 

auto_ptr et exceptions 

Dans certains cas, auto_ptr peut etre d'une grande utilite pour assurer qu'un pro- 
gramme se comporte correctement en presence d'exceptions. Pour preuve, considerez 
la fonction suivante : 

// Que se passe t'il si une exception se produit ? 
// 

String f ( ) 
{ 

String resultat ; 
resultat = "une valeur"; 
cout << "hello ! " 
return resultat ; 

} 

Cette fonction a deux actions exterieures : elle emet un message vers le flux de 
sortie (cout) et retourne une chaine vers le code appelant. Sans entrer dans une discus- 
sion complete sur la robustesse aux exceptions 1 , il faut savoir qu'une des caracteristi- 
ques requises pour le bon comportement d'une fonction en presence d'exceptions est 
son atomicite : la fonction doit s'executer completement ou bien, si elle echoue, lais- 
ser l'etat du programme inchange (en l'occurrence, n' avoir aucune effet exterieur). 

De ce point de vue la, la fonction f { ) presente un defaut, comme le montre 
l'exemple suivant : 

String unNom ; 
unNom = f ( ) ; 

La fonction to renvoyant une valeur, le constructeur de copie de string est 
appele pour copier la valeur retournee par la fonction dans l'objet unNom. Si ce 
constructeur echoue sur une exception, la fonction to ne se sera executee que partiel- 
lement : un message aura ete affiche, mais la valeur n' aura pas ete correctement ren- 
voyee a 1' appelant. 



1. Ace sujet, voir les problemes n° 8 a 19. 
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Pour eviter ce probleme, on peut utiliser une reference non constante passee en 
parametre plutot que retourner une valeur : 

// Est-ce mieux ? 
// 

void f (Strings result) 
{ 

cout << "hello ! " 
resultat = "une valeur" 

} 

Cette solution peut paraitre meilleure, du fait qu'elle evite 1' utilisation d'une 
valeur de retour et elimine, par la meme, les risques lies a la copie. En realite, elle 
pose exactement le meme probleme que la precedente, deplace a un autre endroit : 
c'est maintenant Foperation d' affectation qui risque d'echouer sur une exception, ce 
qui aura egalement pour consequence une execution partielle de la fonction. 

Pour finalement resoudre le probleme, il faut avoir recours a un pointeur pointant 
vers un objet string alloue dynamiquement ou, mieux encore, a un pointeur automa- 
tique (auto_ptr) : 

// La bonne methode 
// 

auto_ptr<String> f() 
{ 

auto_ptr<String> resultat = new String ; 
* resultat = "une valeur"; 

cout << "hello ! " 

return resultat ; // Ne peut pas generer d' exception 

} 

Cette derniere solution est la bonne. II n'y a plus aucun risque de generation 
d' exception au moment de la transmission d'une valeur de retour ou au moment d'une 
affectation. Cette fonction satisfait tout a fait a la technique du « valider ou annuler » : 
si elle est interrompue par une exception, elle annule totalement les operations en 
cours (aucun message affiche a l'ecran, aucune valeur recue par 1' appelant). L' utilisa- 
tion d'un auto_ptr comme valeur de retour permet de gerer correctement la transmis- 
sion de la chaine de caractere a 1' appelant : si 1' appelant recupere correctement la 
valeur de retour, il prendra le controle de la chaine allouee et aura pour responsabilite 
de la desallouer ; si, au contraire, 1' appelant ne recupere pas correctement la valeur de 
retour, la chaine orpheline sera automatiquement detruite au moment de la destruction 
de la variable automatique result. Nous n'avons obtenu cette robustesse aux excep- 
tions qu'au prix d'une petite perte de performance due a Fallocation dynamique. Les 
benefices retires au niveau de la qualite du code en valent largement la peine. 

Prenez l'habitude d'utiliser frequemment les auto_ptrs. lis permettent d'ecrire du 
code plus simple et plus robuste aux exceptions ; de plus, ils sont standards et, par 
consequent, portables. 
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Technique de l'auto_ptr constant 

Pour finir ce chapitre, voyons une technique utile : 1' utilisation d'un auto_ptr 
constant. Un auto_ptr constant ne perd jamais le controle de l'objet vers lequel il 
pointe. Les seules operations permises sur un « const auto_ptr » sont 1' application 
des operateurs * et ->, qui permettent de faire reference a l'objet pointe ou l'appel a la 
fonction membre get ( ) , qui renvoie la valeur du pointeur stocke. 

const auto_ptr<T> ptl ( new T ) ; 

// Le fait de declarer ptl "const" nous assure 

// qu'il ne peut pas etre copie vers un autre_auto_ptr . 

// II conserve ainsi en permanence le controle de "new T" 

auto_ptr<T> pt2 ( ptl ) ; // Interdit 

auto_ptr<T> pt3; 

pt3 = ptl; // Interdit 

ptl . release () ; // Interdit 

ptl. reset ( new T ); // Interdit 

L'utilisation d'un const auto_ptr est une technique couramment repandue, ainsi 
que le mentionne 1' article de la solution originale de ce probleme, paru dans Guru of 
the Week. Nous conclurons de meme ce chapitre :« La technique de l'auto_ptr 
constant fait partie de ces choses devenues tellement courantes qu'on a l'impression 
de les avoir toujours connues. » 
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Pb n° 38. Auto-affectation 



Difficulte : 5 



Dans ce probleme, nous allons etudier le probleme de I'auto affectation et, plus generalement, 
voir comment determiner si deux pointeurs pointent vers un meme et unique objet. 



Lorsqu'on redefinit l'operateur d' affectation pour une classe, il est courant qu'on 
implemente un test preliminaire pour eviter une « auto- affectation » : 

T& T : : operator= ( const T& other ) 
{ 

if ( this != Sother ) //he test en question 

{ 

// ... 

} 

return *this; 

} 

L'instruction « this ! sother » utilisee ici est-elle necessaire et/ou suffisante pour 
realiser correctement le test ? Vous argumenterez votre reponse et proposerez, le cas 
echeant, une meilleure solution. 




Reponse courte : un operateur d' affectation correctement implemente devrait bien 
se comporter dans toutes les situations, meme en cas d' auto-affectation; le test pro- 
pose n'est done pas indispensable. 
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Reponse longue : dans certains cas, il peut etre justifie d'utiliser ce type de test, en 
prenant neanmoins garde au fait qu'il peut poser probleme dans une situation bien 
precise (redefinition de la fonction operators) 1 

Eviter I'auto-affectation ? 

Le test evitant I'auto-affectation ne devrait pas etre necessaire : autrement dit, 
1' implementation de l'operateur d' affectation devrait fonctionner correctement pour 
tout type d' affectation, y compris dans le cas particulier de I'auto-affectation : 



Recommandation 

Ne traitez jamais I'auto-affectation comme un cas particulier : ^implementation generale 
d'un operateur d'affectation doit etre capable de gerer correctement I'auto-affectation. 



II peut etre justifie, dans certains cas, d'utiliser un test de ce genre pour eviter une 
auto-affectation, inutile et penalisante en terme en performances. Neanmoins, il faut 
en reserver l'emploi aux - rares - situations ou le gain de performances est vraiment 
notable (operation d'affectation particulierement couteuse et/ou nombre d' auto-affec- 
tations particulierement eleve). 



Recommandation 

Vous pouvez utiliser un test pour eviter I'auto-affectation dans les cas ou cela procure un 
gain de performance. 



Redefinition de l'operateur & 

II est tout a fait possible qu'une classe redefinisse l'operateur s (ou qu'il soit rede- 
fini dans une des classes de base) en lui donnant un comportement tout a fait different 
du comportement normal « obtenir l'adresse de... ». Auquel cas, le code 
« this ! =&other » risque de donner un resultat different de celui escompte. Soit dit en 
passant, l'auteur d'une classe ayant implemente un test pour eviter I'auto-affectation 
serait un peu machiavelique de redefinir la fonction operators ! 

Au passage, on peut noter que si la classe redefmit t : : operator ! ( ) , ceci n'a pas 
d'influence sur le test « this!=sother » car cette fonction ne sera pas appelee (en 
effet, la fonction t : : operator ! ( ) doit obligatoirement prendre au moins un parametre 
de type t, et ne peut done pas prendre deux parametres de type t*). 



1. Contrairement a ce que Ton peut parfois lire, il n'y a aucun probleme lie a l'utilisation 
de l'heritage multiple. 
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Construction et auto-affectation 

Dans le meme ordre d'idees, voici un exemple de code parfois rencontre : 

T : : T ( const T& other ) 
{ 

if ( this ! = Sother ) 
{ 

// ... 

} 

} 

J'espere que vous avez trouve l'erreur du premier coup 1 . 



Quelques complements au sujet des pointeurs 

Voici pour finir deux exemples de resultats inattendus pouvant se produire lors de 
comparaisons de pointeurs : 

■ Comparer deux pointeurs pointant vers des chaines de caractere litterales peut 
donner des resultats inattendus : en particulier, si vous comparez deux pointeurs 
vers deux variables chaines litterales distinctes ayant la meme valeur, il est possi- 
ble que ces deux pointeurs contiennent la meme adresse. En effet, a des fins 
d' optimisation, la norme C++ autorise explicitement les compilateurs a ne pas 
stacker systematiquement chaque nouvelle chaine litterale dans un espace 
memoire separe. 

■ La comparaison de valeurs de pointeurs a l'aide des operateurs <, <=, > et >= pro- 
duit en general un resultat indetermine (sauf dans certains cas particuliers comme 
la comparaison de pointeurs vers des objets stockes dans un meme tableau). Cette 
limitation peut etre contournee par l'emploi du modele de fonction iess<> et de 
ses cousins, qui permettent d'etablir une relation d' ordre entre des pointeurs. Ces 
fonctions sont utilisees, entre autres, lorsque Ton cree une table de correspondance 
utilisant un cle de type pointeur - par exemple map<T*, u> (qui est en fait, apres 
resolution du parametre par defaut : map<T*, u, iess<T*>>) . 



1. Verifier si on n'est pas en train d'effectuer une auto-affectation n'a aucun sens dans le 
cas d'un constructeur : l'objet « other » ne peut pas etre egal a l'objet qu'on est en train 
de construire, pour la bonne raison que ce dernier n'existe pas encore ! Un de mes amis, 
Jim Hyslop, m'a fait remarquer que l'exemple suivant (techniquement illegal) utilisant 
un operateur new avec « placement » (adresse d' allocation forcee) donnerait un sens, 
s'il etait legal, a ce test dans le constructeur : 
T t ; 

new (st) T(t) ; // Donnerait un sens au test si c'est legal 

Autre exemple dans lequel ce test serait utile : « T t = t ; », instruction acceptee par 

le compilateur mais qui provoquera immanquablement une erreur a 1' execution. 
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Pb n° 39. Conversions automatiques Difficulte : 4 



Les conversions automatiques d'un type a un autre sont extremement pratiques. Elles peuvent 
egalement etre extremement dangereuses, comme nous allons le voir dans ce probleme. 



Comme vous le savez, la classe string de la bibliotheque standard C++ n'imple- 
mente pas de conversion automatique vers le type const char* mais fournit, a la 
place, une fonction membre c_str ( ) renvoyant un const char* : 

string si ("hello") , s2 ( "world" ) ; 

strcmp ( si, s2 ) ; // 1 (Erreur) 

strcmp ( sl.c_str(), s2.c_str() ) // 2 (OK) 

Dans cet exemple, le premier appel a strcmp provoque une erreur de compilation 
car il n'existe pas de conversion de string vers const char*. Le second appel se 
compile correctement, mais est plus lourd a ecrire; on est des lors rente de deplorer 
que la syntaxe du premier appel soit interdite... 

A votre avis, pour quelle(s) raison(s) la classe string n'implemente-t-elle pas de 
conversion vers const char ? 



II est toujours dangereux d'implementer des conversions implicites - qu'il 
s'agisse d'operateurs de conversion ou de constructeurs a un argument (sauf s'ils sont 
declares explicit) 1 . En effet : 

■ Les conversions implicites peuvent etre a l'origine de surprises lors de la resolu- 
tion de noms. 

■ Les conversions implicites peuvent rendre possible la compilation d'un code pour- 
tant « incorrect ». 

Si la classe string implementait une conversion automatique vers const char*, 
cette conversion risquerait d'etre appelee de maniere implicite par le compilateur sans 
que l'utilisateur ne s'en rende systematiquement compte, pouvant ainsi causer ainsi 
toutes sortes de problemes parfois difficiles a reperer, car ne provoquant en general 
pas d'erreurs de compilation. De nombreux exemples pourraient etre cites, en voici 
un : 

string si, s2, s3; 

si = s2 - s3; // Faute de f rappe . . . au lieu de 



1. Nous n'abordons ici que les problemes courants lies aux conversions implicites. II y a 
d'autres raisons qui justifient 1' absence de conversion de string vers const char*. A 
ce sujet, voir Koenig A. and Moo B. Ruminations on C++ (Addison Wesley Longman, 
1997), pages 290 a 292 ; Stroustrup Bjarne The Design and Evolution of C++ (Addiso 
Wesley, 1994), page 83. 
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Si la classe string implementait une conversion automatique vers const char, le 
code ci-dessus se compilerait correctement mais, a 1' execution, s2 et s3 seraient 
convertis vers des const char* et la soustraction des deux pointeurs resultants serait 
affectee a s l ! 



Recommandation 

Evitez d'implementer des operateurs de conversion. Declarez les constructeurs 'explicit' 



Pb n° 40. Duree de vie des objets (1 re partie) Difficulte : 5 



Allocation, construction, destruction, deallocation... A quel moment un objet est-il vrai- 
ment utilisable ? 



Examinez le code suivant : 

void f() 
{ 

T t(l); 
TS rt = t; 

// #1: on manipule t et rt 

t . ~T ( ) ; 

new (&t) T (2) ; 

// #2 : on manipule t et rt 

} // t est detruit automatiquement 

Le bloc de code #2 va-t-il s'executer correctement ? 



Solution 



Le code propose est legal et conforme a la norme C++ ; neanmoins, la fonction 
dans son ensemble n'est pas saine - elle peut poser des problemes en presence 
d' exceptions - et utilise un style de programmation qu'il vaut mieux eviter. 

Nous operons ici une destruction explicite suivi d'une allocation « placee » (allo- 
cation a une adresse memoire determinee) : la norme C++ specifie clairement qu'une 
reference (en 1' occurrence rt) ne doit pas etre alteree par une operation de ce type 
(bien entendu, on fait ici l'hypothese que l'operateur & n'a pas ete redefini pour la 
classe t et renvoie bien l'adresse de l'objet). 

En revanche, la fonction f ( ) peut se comporter de maniere incorrecte en presence 
d' exceptions : en effet, si une exception se produit lors de la « reconstruction » de t 
(« new (&t) T(2) »), alors la fonction va se terminer et un appel au destructeur t :: ~t 
se produira, ce qui posera probleme car la zone memoire de t ne contiendra alors 
aucun objet construit. Autrement dit, en presence d' exception, t risque d'etre construit 
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une fois mais detruit deux fois, ce qui provoquera a coup sur une erreur a l'execution. 



Recommandation 

Assurez-vous que votre code se comporte correctement en presence d'exceptions. En par- 
ticulier, organisez votre code de maniere a desallouer correctement les objets et a laisser les don- 
nees dans un etat coherent, meme en presence d'exceptions. 



Independamment de ces questions relatives aux exceptions, il n'est pas recom- 
mande de prendre 1' habitude d' avoir recours a cette technique de destruction explicite 
/ allocation placee. Si elle n'est pas dangereuse utilisee depuis du code client de t, elle 
peut en revanche poser probleme depuis certaines fonctions membres : 

// Avez-vous vu le danger ? 
// 

void T : : DestroyAndReconstruct ( int i ) 
{ 

this->~T ( ) ; 

new (this) T (i) ; 

} 

Ce code est dangereux ! Pour preuve, examinez le code suivant : 

class U : public T {/*...*/ }; 

void f() 

{ 

/ *AAA* / t (1) ; 
/*BBB*/& rt = t; 

// #1: on manipule t et rt 

t . DestroyAndReconstruct (2 ) ; 

// #2: on manipule t et rt 

} // t est detruit automatiquement 

Si « / *aaa* / » vaut « t », le code du bloc #2 s'executera correctement, que « / 
*bbb* / » soit « t » ou une classe de base de « t ». 

En revanche, si « /*aaa*/ » vaut « u », il se produira a coup sur une erreur a l'exe- 
cution, et ce, quelle que soit la valeur de « /*bbb*/ » : en effet, l'appel a 
DestroyAndReconstruct ( ) remplacera l'objet t de type u par un objet plus petit, de 
type t. La bonne execution de la suite depend de la partie de u utilisee par le code du 
bloc #2 : si ce code appelle des fonctions implementees dans u et pas dans t, une 
erreur se produira. 

En conclusion, meme si elle fonctionne dans certains cas, cette technique dange- 
reuse n'est pas recommandable. 



Recommandation 

Ne poussez pas le langage dans ses derniers retranchements. Les techniques les plus sim- 
ples sont souvent les meilleures. 
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Pb n° 41 . Duree de vie des objets (2 e partie) Difficulte : 6 



Ce probleme etudie plus en detail la technique de destruction explicite / reallocation placee 
deja entrevue au cours du probleme precedent. Parfois utile, cette pratique presente neanmoins 




Examinez le code suivant : 

T& T : : operator= ( const T& other ) 
{ 

if ( this ! = Sother ) 
{ 

this->~T () ; 

new (this) T (other) ; 

} 

return *this; 

} 

1. Quel est l'interet d'implementer l'operateur d'affectation de cette maniere ? Ce 
code presente-t-il des defauts ? 

2. En faisant abstraction des defauts de codage, peut-on considerer que la technique 
utilisee ici est sans danger ? Sinon, quelle(s) autre(s) technique(s) pourrai(en)t per- 
mettre d'obtenir un resultat equivalent ? 

Note : Voir aussi le probleme n° 40. 




La technique de destruction explicite / reallocation placee utilisee dans cet exem- 
ple est parfaitement legale et conforme a la norme C++ (ou elle est meme citee en 
exemple, voir plus loin la discussion sur ce sujet). Neanmoins, elle peut etre a l'ori- 
gine d'un grand nombre de problemes, comme nous allons le montrer ici 1 . D'une 
maniere generate, il est preferable de ne pas utiliser cette technique de programma- 
tion, d'autant plus qu'il existe un moyen plus sur d'aboutir au meme resultat. 

L'interet majeur de cette technique est le fait que l'operateur d'affectation est 
implemente en fonction du constructeur de copie, assurant ainsi une identite de com- 
portement entre ces deux fonctions. Ceci permet de ne pas a avoir repeter inutilement 
deux fois le meme code et elimine les risques de desynchronisation lors des evolutions 
de la classe - par exemple, plus de risque d'oublier de mettre a jour une des deux 
fonctions lorsqu'on ajoute une variable membre a la classe. 



1. Nous ne traiterons pas ici le cas trivial de la redefinition de l'operateur & (il est evident 
que cette technique ne fonctionne pas si l'operateur & renvoie autre chose que 
« this » ; voir le probleme n° 38 a ce sujet). 
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Cette technique s'avere egalement utile - voire indispensable - dans un cas parti- 
culier : si la classe t a une classe de base virtuelle comportant des variables membres, 
Foperation de destruction / reallocation assure que ces variables membres seront cor- 
rectement copiees 1 . Neanmoins, ce n'est qu'un maigre argument car, d'une part une 
classe de base virtuelle ne devrait pas contenir de variables membres (voir, a ce sujet, 
Meyers98, Meyers99 et Barton94) et d'autre part le fait que t comporte une classe de 
base virtuelle indique tres probablement qu'elle est elle-meme destinee a servir de 
classe de base, ce qui va poser probleme (comme nous allons le voir dans la section 
suivante). 

Si F utilisation de cette technique presente quelques rares avantages, elle induit 
malheureusement beaucoup de problemes, que nous allons detailler maintenant. 

Probleme n° 1 : Troncature d'objets 

Le code « this->~T o ; new (this) t (other) ; » presente un defaut : il pose pro- 
bleme lorsque t est une classe de base dotee d'un destructeur virtuel et que la fonction 
t : : operator ( ) = est appelee depuis un objet derive. Dans ce cas de figure, Foperateur 
d'affectation va detruire Fobjet derive et le remplacer par un objet t, plus petit. Cette 
« troncature » de Fobjet derive provoquera immanquablement des erreurs d' execution 
dans la suite du code (voir egalement le probleme n° 40 a ce sujet). 

II est d'usage, pour Fauteur d'une classe derivee, d'implementer Foperateur 
d'affectation de sa classe en fonction de Foperateur de la classe de base : 

Der ived& 

Derived :: operator= ( const DerivedS other ) 
{ 

Base : : operator= ( other ); 

// . . . On effectue ici la copie des membres de Derived 
return *this; 

} 

Si la classe t de l'exemple etait utilisee comme classe de base, voici ce que cela 
donnerait : 

class U : T {/*...*/} ; 

U& U : : operator= ( const U& other ) 
{ 

T : : operator= ( other ); 

// ...On effectue ici la copie des membres de U 
// ... PROBLEME : 'this' n'est plus un U mais un T ! 
return *this; // Ne pointe pas vers un U ! 

} 



1 . Alors que sans cette technique, les variables en question seront, au mieux, copiees plu- 
sieurs fois et, au pire, copiees de maniere incorrecte. 
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Non settlement la fonction t : : operator ( ) = perturbe la suite du code, mais encore 
elle le fait de maniere silencieuse : il est en general tres difficile de deboguer ce genre 
d'erreur si on n'a pas acces au code source de t (a moins que le destructeur de u 
n'affecte aux variables membres des valeurs permettant de detecter clairement que 
l'objet a ete detruit, mais c'est une bonne habitude malheureusement trop peu repan- 
due). 

II y a deux solutions pour corriger ce defaut du code : 

■ Remplacer l'appel explicite a t: : operator o= par un appel a «this->~T() » 
suivi d'une reallocation de l'objet de base t a l'adresse this. Ceci permettrait de 
s'assurer que, lors d'un appel a cet operateur depuis un objet derive u, seul l'objet 
de base t est detruit et reconstruit, evitant ainsi la troncature de l'objet u. 

■ Appliquer dans la fonction u: : operator o = la meme technique que celle 
employee dans t : : operator ( ) =. Cette solution est meilleure que la premiere mais 
met bien en evidence l'une des faiblesses de la technique destruction explicite / 
reallocation : si elle est utilisee dans une classe de base, elle doit etre utilisee dans 
toutes les classes derivees (ce qui est tres difficile a mettre en oeuvre en pratique 
car il faut imposer aux auteurs des classes derivees d'implementer un operateur 
d' affectation specifique). 

Si elles permettent de limiter les degats, ces deux solutions presentent neanmoins 
quelques pieges, sur lesquels nous allons avoir l'occasion de revenir bientot. 



Recommandations 

Ne poussez pas le langage dans ses derniers retranchements. Les techniques les plus sim- 
ples sont souvent les meilleures. 

Evitez le code inutilement complique ou obscur, meme s'il vous parait simple et clair au 
moment ou vous I'ecrivez. 



Probleme n° 2 : Mauvais comportement 
en presence d exceptions 

Quand bien meme le code de l'exemple aurait ete corrige, grace a l'une des deux 
techniques presentees ci-dessus, il subsisterait de toute maniere un certain nombre de 
problemes impossibles a eliminer. 

Le premier d'entre eux concerne le comportement du code en presence d'excep- 
tions : si le constructeur de copie de t lance une exception lors de l'appel a « new 
(this) t (other); » (c' est le mode naturel qu' utilise un constructeur pour signaler 
des erreurs), alors la fonction T: :operator= o se terminera prematurement en lais- 
sant l'objet t dans un etat incoherent (l'ancien objet aura ete detruit, mais n'aura pas 
ete remplace). 
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II risque alors de se produire une erreur d' execution dans la suite du code : tenta- 
tive de manipulation d'un objet qui n'existe plus ou tentative de double destruction 
(au sujet de ce dernier point, voir le probleme n° 40). 



Recommandation 

Assurez-vous que votre code se comporte correctement en presence d'exceptions. En par- 
ticulier, organisez votre code de maniere a desallouer correctement les objets et a laisser les don- 
nees dans un etat coherent, meme en presence d'exceptions. 



Probleme n° 3 : Alteration de la notion de duree 
de vie 

Un autre inconvenient majeur de la technique de destruction explicite / realloca- 
tion est qu'elle est incoherente avec la notion classique de duree de vie d'un objet. En 
particulier, elle risque de perturber le comportement de toute classe realisant 
1' « acquisition » d'une ressource externe lors de sa construction et sa « liberation » 
lors de sa destruction. 

Prenons l'exemple d'une classe se connectant a une base de donnees lors de sa 
construction et s'en deconnectant lors de sa destruction : realiser une operation 
d' affectation sur une instance de cette classe provoquera une deconnexion / 
reconnexion intempestive, risquant de laisser l'objet et ses clients dans un etat incohe- 
rent - (ils utiliseront une connexion differente de celle qu'ils croiront utiliser). On 
aurait pu egalement prendre l'exemple d'une classe verrouillant une section critique 
lors de sa construction et la liberant lors de sa destruction. 

Vous pourriez arguer que l'emploi d' operations de ce genre est limite a un certain 
type de programmes et que vous ne l'utilisez pas dans vos classes. C'est possible, 
mais qui vous assure qu'une de vos classes de base ne le fait pas ? D'une maniere 
generale, il ne faut pas utiliser de techniques de programmation imposant des 
contraintes sur les classes de bases parce qu'il n'est pas possible de mattriser ce que 
contient une classe de base lorsqu'on implemente une classe derivee. 

Le probleme de fond est cette technique est contradictoire avec le sens meme de 
construction et destruction en C++. La construction doit correspondre au debut de la 
vie de l'objet et la destruction a la fin de la vie, alors qu'ici on detruit un objet et on le 
remplace par un autre, tout en voulant faire croire au code exterieur que l'objet initial 
n'a pas cesse de « vivre » mais qu'il a simplement change de valeur : ceci pose des 
problemes lorsque le constructeur et le destructeur effectuent des operations specifi- 
ques comme l'acquisition et la liberation de ressources externes. 

Probleme n° 4 : Perturbation des classes derivees 

La solution vue plus haut consistant a appeler explicitement le destructeur de T 
(this ->t : : ~t ( ) ) pour eviter la troncature d'un objet derive presente 1' inconvenient 
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d'aller a l'encontre du principe classique selon lequel les objets de base sont 
construits avant et detruits apres l'objet derive. Dans de nombreuses situations, cela 
peut poser probleme pour un objet derive de voir un de ses objets de base detruit puis 
remplace sans qu'il le sache (bien que les consequences soient limitees lorsque 1' ope- 
ration d'affectation n'effectue que des affectations « classiques » de membres... mais 
dans ce cas-la, quel est l'interet de le redefinir ?). 

Probleme n° 5 : this ! = sother 

L'exemple de code est totalement dependant du test preliminaire « this ! = 
sother » : pour vous en convaincre, imaginez ce qui se passerait, sans ce test, dans le 
cas d'une auto-affectation. Par consequent, nous avons le meme probleme que celui 
qui a ete expose dans le probleme n° 38 : notre operateur traite 1' auto-affectation 
comme un cas particulier, alors qu'un operateur d'affectation correctement imple- 
mente devrait, sous sa forme generate, bien se comporter dans toutes les situations, 
meme en cas d' auto-affectation 1 . 

A ce point du discours, nous avons decouvert suffisamment de problemes lies a 
1' utilisation de cette technique de destruction explicite / reallocation pour conclure 
sans scrupule que c'est une technique a eviter 2 . 

Nous allons a present voir qu'il existe une autre solution pour mutualiser le code 
du constructeur de copie et de 1' operateur d'affectation sans subir les inconvenients de 
la technique precedente. 

Cette solution est fondee sur 1' utilisation d'une fonction membre swapo, imple- 
mented de maniere a ne jamais lancer d'exception, realisant Vechange de la valeur de 
l'objet sur lequel elle est appliquee avec celle de l'objet passe en parametre : 

T& T : : operator= ( const T& other ) 



Cette methode implemente l'operateur d'affectation en fonction du constructeur 
de copie; elle ne tronque pas les objets, se comporte correctement en presence 
d' exceptions, n'altere pas la notion de classe derivee et traite sans probleme le cas de 
1' auto-affectation. Nul doute qu'elle doit, sans conteste, etre preferee a la methode 
precedente ! 



1. II est tout a fait possible d'utiliser un test de ce genre a des fins d' optimisation. En 
revanche, votre operateur doit etre implemente de maniere a traiter correctement 1' auto- 
affectation, meme en l'absence de test. Reportez vous au probleme n° 38 pour plus 
d' informations. 

2. Et encore, tous les problemes n'ont pas ete traites ici (notamment le comportement 
incoherent en presence d'operateur d'affectation virtuel). 



T temp ( other ) ; 
Swap ( temp ) ; 
return *this; 



// 
// 
// 



Prepare le travail 

"Valide" le travail (sans risquer 

de lancer une exception) 
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Pour plus d' informations a propos cette methode en particulier et sur la gestion 
correcte des exceptions en general, voir egalement les problemes 8 a 17 1 . 



Recommandations 

Implementez I'operateur d'affectation en fonction du constructeur de copie en utilisant 
une fonction swap ( ) ne lancant pas d'exception : 

// Bon 

T& T : : operator= ( const T& other ) 
{ 

T temp ( other ) ; 
Swap ( temp ) ; 
return *this; 

} 

N'utilisez jamais la technique consistant a implementer I'operateur d'affectation en fonction du 
constructeur de copie en ayant recours a une destruction explicite suivi d'une allocation placee 
- meme si cette technique est parfois recommandee par certains. 

Autrement dit, n'ecrivez PAS : 

// MAUVAIS 

T& T : : operator= ( const T& other ) 
{ 

if ( this != Sother) 
{ 

this->~T(); // Dangereux ! 

new (this) T( other ) ; // Dangereux ! 

} 

return *this; 

} 



Du bon usage des exemples 

La technique tant denigree dans les sections precedentes est citee comme exemple 
dans la norme C++ ! 

Nous reproduisons ici Fexemple en question (extrait de la section 3.8 §7, legere- 
ment simplifie a des fins de clarte) afin de montrer qu'il est destine qu'a illustrer quel- 
ques regies relatives a la duree de vie des objets et n' encourage en aucun cas 1' usage 
systematique de la destruction / reallocation : 



1 . Cette methode, il est vrai, ne fonctionne pas pour une classe ayant des membres de type 
reference. Cela ne remet pas en cause l'efficacite de la methode car des objets contenant 
des membres de type reference devraient normalement ne pas pouvoir etre copies (si on 
desire pouvoir le faire, il faut utiliser des membres de type pointeur). 
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// Exemple extrait de la norme C++ 
struct C f 
int i; 
void f () ; 

const C& operator= ( const C& ) ; 

}; 

const C& C : : operator= ( const C& other) 

{ 

if ( this != Sother ) 
{ 

this->~C(); // Fin de la vie de *this 

new (this) C (other) ; 

// Creation d' un nouvel objet C 
f ( ) ; // S' execute correctement 

} 

return *this; 

} 

C cl; 
C c2; 

cl = c2; // S' execute correctement 

cl.f(); // S' execute correctement. cl est un nouvel objet C 
cl.f(); // S' execute correctement. cl est un nouvel objet C 

Au passage, on peut remarquer que cet exemple presente un petit defaut : l'opera- 
teur c : : operator= ( ) renvoie un const c& plutot que de renvoyer un cs. Bien que ce 
choix permette d'eviter des usages abusifs comme (« (a=b) =c »), il interdit 1' utilisa- 
tion des objets de type c avec les conteneurs de la bibliotheque standard, qui requie- 
rent que l'operateur d' affectation renvoient une reference non constante (voir Cline 
95 :212 et Murray 93 : 32-33) 

Eloge de la simplicity 

Restez simples. N'utilisez pas les fonctionnalites avancees du langage C++, meme 
si elles sont tentantes, a moins d'en maitriser parfaitement les consequences. En un 
mot, n'ecrivez jamais du code que vous comprenez pas. 

En premier lieu, cela risque de poser des problemes de portability car, d'une part il 
est dangereux d'utiliser trop vite les nouvelles fonctionnalites d'un langage, les compila- 
teurs ne les implementant pas tous dans le meme delai (aujourd'hui, certains compila- 
teurs ne gerent pas encore, par exemple, les arguments par defaut pour les modeles ni la 
specialisation des modeles) et, d' autre part certains compilateurs font purement et sim- 
plement l'impasse sur quelques fonctionnalites avancees du langage, existant pourtant 
depuis de nombreuses annees (la gestion des exceptions multiples, par exemple). 

En second lieu, cela risque de compliquer la maintenance : l'une des forces, mais 
aussi l'un des dangers du langage C++ est la possibilite qu'il offre d'ecrire du code 
tres concis. Un code trop elliptique pourra vous paraitre particulierement elegant sur 
le moment mais s'averer etre un cauchemar pour la personne qui s'y replongera des 
mois ou des annees plus tard pour en assurer la maintenance - et pensez que cette per- 
sonne, ce peut etre vous ! 
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Par exemple, une bibliotheque graphique bien connue utilisait la surcharge des 
operateurs pour implementer une fonction operator+o permettant d'ajouter un 
controle graphique a une fenetre : 

Window w ( /*...*/ ) ; 
control c( /*...*/ ); 
w + c ; 

Certes, cette astuce a pu paraitre elegante au premier abord mais, a 1' usage elle 
s'est averee etre une grande source de confusion pour les developpeurs. Les auteurs de 
cette bibliotheque auraient mieux fait de suivre le conseil avise de Scott 
Meyer : « faites comme font les ints » (autrement dit, conformez-vous toujours a la 
semantique des types predefinis lorsque vous redefinissez des operateurs). 

N'ecrivez que ce que vous maitrisez, tout en experimentant peu a peu de nouvelles 
choses : lorsque vous ecrivez un programme, faites en sorte de maitriser parfaitement 
90% du code, et, utilisez les 10% restants pour acquerir de l'experience sur des fonc- 
tionnalites que vous connaissez moins. Si vous etes debutant en C++, ecrivez au debut 
90% du programme en C et introduisez progressivement les ameliorations apportees 
par le C++. 

Maitrisez ce que vous ecrivez : soyez toujours conscient de toutes les operations 
implicites effectuees par votre code, maitrisez-en les consequences eventuelles. 
Tenez-vous regulierement au courant des pieges du C++ en lisant des livres comme 
celui que vous avez entre les mains, en consultant des groupes de discussion Internet 
comme comp.lang.c++.moderated ou comp.std.c++ ou des magazines comme C/ 
C++ User's Journal et Dr. Dobb's Journal. Ceci vous permettra de rester toujours au 
meilleur niveau et de maitriser a fond le langage que vous utilisez quotidiennement. 

Gardez toujours un regard critique face a ces sources d' informations. Que penser 
du fait que la technique dont nous venons d'etudier les defauts - implementation de 
l'operateur d' affectation en fonction du constructeur de copie en utilisant une destruc- 
tion explicite suivie d'une allocation placee - est souvent citee en exemple dans des 
groupes de discussion Internet ? C'est bien la preuve que certains ne maitrisent pas ce 
qu'ils ecrivent, ignorant que cette technique peut presenter des dangers certains et 
qu'il faut lui preferer le recours a une fonction membre privee swap ( ) appelee depuis 
le constructeur de copie et l'operateur d' affectation. 

En conclusion, comme nous l'avons deja dit, evitez de pousser le langage dans ses 
derniers retranchements. Ne succombez jamais a la tentation d'une apparente ele- 
gance, potentielle source de problemes subtils. N'ecrivez que ce que vous maitrisez et 
maitrisez ce que vous ecrivez. 
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MaTtrisez-vous toujours parfaitement ce que vous ecrivez ? Pour le verifier, examinez les quatre 
lignes de code proposees ici : leur syntaxe est tres proche, mais elles ont toutes un comporte- 




Quelle est la difference entre ces quatre lignes de code ? 

T t; 

T t ( ) ; 

T t (u) ; 

T t = u; 

(t designe une classe) 




Ces lignes illustrent trois differentes formes d' initialisation possibles pour un 
objet : initialisation par defaut, initialisation directe et initialisation par le constructeur 
de copie. Quant a la quatrieme forme, il s'agit d'un petit piege a eviter ! 

Prenons les lignes dans l'ordre : 

T t; 

II s'agit ici d'une initialisation par defaut : cette ligne declare une variable de type 
t, nominee t, initialisee par le constructeur par defaut t : : t ( ) . 

T t ( ) ; 

Voici le piege ! Merae si elle ressemble a une initialisation de variable, cette ligne 
n' initialise rien du tout : elle est interpretee par le compilateur comme la declaration 
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d'une fonction nominee t, ne prenant aucun parametre et renvoyant un objet de type t 
(si cela ne vous semble pas evident, remplacez le type t par int et le nom t par f : 
cela donne « int f ( ) ; » ce qui est clairement une declaration de fonction). 

D'aucuns suggerent qu'il est possible d'utiliser la syntaxe « auto t t o ; » pour 
bien specifier au compilateur qu'on souhaite declarer et initialiser un objet automati- 
que t de type t, et non pas une fonction nominee t renvoyant un t. Ce n'est pas une 
pratique recommandable, pour deux raisons. La premiere est que cela ne marchera 
qu'avec certains compilateurs - au passage non conformes a la norme C++, un compi- 
lateur correctement implemente devant rejeter cette ligne en indiquant qu'il n'est pas 
possible de specifier le qualificatif 'auto' pour un type de retour de fonction. La 
seconde est qu'il y a une technique beaucoup plus simple pour obtenir le meme resul- 
tat : ecrire « t t ; ».Ne cherchez pas la complication lorsque vous ecrivez un pro- 
gramme ! La maintenance de votre code n'en sera que plus facile. 

T t (u) ; 

II s'agit ici de V initialisation directe. Lobjet t est initialise des sa construction a 
partir de la valeur de la variable u, par appel du constructeur t : : t (u) . 

T t = u; 

II s'agit, pour finir, de V initialisation par le constructeur de copie. Lobjet t est 
initialise par le constructeur de copie de t, lui-meme eventuellement precede par 
1' appel d'une autre fonction. 



Erreur courante 

II ne faut pas confondre initialisation par le constructeur de copie et affectation. En depit 
de la presence d'un signe =, I'instruction « t t=u; » n'appelle pas t : :operator= o . 



Cette derniere initialisation fonctionne de la maniere suivante : 

■ Si u est de type t, cette instruction est equivalente a « t : :t (u) » (le constructeur 
de copie de t est appele directement). 

■ Si u n'est pas de type t, cette instruction est equivalente a « t t (t (u) ) ; » (u est 
converti en un objet temporaire de type t, lui-meme passe en parametre au 
constructeur de copie de t). II faut savoir qu'en fonction du niveau d' optimisation 
demande, certains compilateurs pourront eventuellement supprimer cet appel au 
constructeur de copie pour le remplacer par une initialisation directe du type « t 
t (u) ». II ne faut done pas que la coherence de votre code repose sur l'hypothese 
que le constructeur de copie sera systematiquement appele dans une initialisation 
de ce type. 



Recommandation 

Preferez, lorsque cela est possible, I'emploi d'une initialisation de type « t t <u) » au lieu de 
« t t = u; ». Ces deux instructions sont fonctionnellement equivalentes, mais la premiere pre- 
sente plus d'avantages - comme, en particulier, la possibility de prendre plusieurs parametres. 




© copyright Editions Eyrolles 



Pb n° 43. Du bon usage de const 



183 



Pb n° 43. Du bon usage de const Difficulty : 6 



const est un outil puissant, pouvant contribuer nettement a la stabilite et a la securite d'un 
programme. II faut neanmoins etre judicieux dans son utilisation. Ce probleme presente quel- 




Examinez le programme ci-dessus. Sans en changer la structure - legerement 
condensee a des fins de clarte - commentez l'utilisation des mots-cles const. 

Proposez une version corrigee du programme a laquelle vous aurez ajoute ou ote 
des const (et effectue les eventuels changements mineurs correlatifs) 

Question supplementaire : y a t'il, dans le programme original, des instructions 
pouvant provoquer des erreurs a Fexecution en raison de const oublies ou, au 
contraire, superflus ? 

class Polygon 
{ 

public : 

Polygon)) : area_(-l) {} 

void AddPoint ( const Point pt ) { InvalidateArea ( ) ; 

points_.push_back (pt) ; } 
Point GetPoint ( const int i ) { return points_[i]; } 

int GetNumPoints ( ) { return points_. size ( ) ; } 

double GetAreaO 
{ 

if ( area_ < 0 ) //Si l'aire n'a pas ete calculee... 

{ 

CalcAreaO; // ...on la calcule 

} 

return area_; 

} 

private : 

void InvalidateArea ( ) { area_ = -1; } 

void CalcAreaO 

{ 

area_ = 0; 

vector<Point> :: iterator i; 

for ( i = points_. begin () ; i != points_. end ( ) ; ++i ) 
area_ += /* calcul de l'aire (non detaille ici) */; 

} 

vector<Point> points_; 
double area_; 

}; 

Polygon operatort ( Polygons lhs, Polygons rhs ) 
{ 

Polygon ret = lhs; 

int last = rhs . GetNumPoints () ; 

for ( int i = 0; i < last; ++i ) // concatenation des points 
{ 

ret .AddPoint ( rhs . GetPoint ( i ) ); 
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} 

return ret; 

} 

void f ( const Polygons poly ) 
{ 

const_cast<Polygon&> (poly) . AddPoint ( Point (0,0) ); 

} 

void g( Polygons const rPoly ) { rPoly .AddPoint ( Point (1,1) ) ; ) 

void h( Polygon* const pPoly ) { pPoly->AddPoint ( Point (2,2) ); } 

int main ( ) 
{ 

Polygon poly; 

const Polygon cpoly; 

f (poly) ; 
f (cpoly) ; 
g (poly) ; 
h (spoly) ; 

} 



f S ° LUT,0N 

Ce probleme est l'occasion de signaler, d'une part, des erreurs courantes dans 
l'utilisation de const, et egalement, d'autre part, des situations plus subtiles pouvant 
requerir - ou non - l'utilisation de const (voir notamment le paragraphe « const et 
mutable : des amis qui vous veulent du bien ») 

class Polygon 
{ 

public : 

Polygon () : area_(-l) {) 

void AddPoint ( const Point pt ) { InvalidateArea ( ) ; 

points_.push_back (pt) ; } 

1. L'objet Point etant passe par valeur, il n'y a aucun interet a le declarer const, 
etant donne que la fonction n'aura, de toute facon, aucune possibilite de modifier 
l'objet original. 

Signalons au passage que deux fonctions ayant la meme signature et ne differant 
que par les attributs const des parametres passes par valeur sont considerees comme 
une seule et meme fonction par le compilateur (pas de surcharge) : 

int f ( int ) ; 

int f( const int ); // re-declaration f(int) 

// Pas de surcharge, une seule fonction f 

int g ( intS ) ; 

int g( const intS ); // Surcharge 

// Pas la meme fonction que g(ints) 
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Recommandation 

II n'est pas necessaire de specifier I'attribut const au niveau de la declaration de la fonc- 
tion pour un parametre passe par valeur. En revanche, si ce parametre n'est pas modifie par la 
fonction, specifiez I'attribut const au niveau de la definition. 



Point GetPoint ( const int i ) { return points_[i]; } 

2. Merae commentaire. II est inutile de declarer const un parametre passe par valeur. 

3. En revanche, la fonction GetPoint ( ) devrait etre declaree const car elle ne modi- 
fie pas l'etat de l'objet. 

4. GetPoint o devrait plutotretourner un « const Point », afin d'eviter que le code 
appelant ne modifie l'objet temporaire renvoye lors de l'execution de la fonction. 
C'est une remarque generate s'appliquant a toutes les fonctions renvoyant un parame- 
tre par valeur (sauf lorsqu'il s'agit d'un type predefini comme int ou long) 1 . 

Au passage, on pourrait se demander pourquoi GetPoint o ne renvoie pas une 
reference plutot qu'une valeur, permettant ainsi aux appelants de placer la valeur 
retournee a gauche d'un operateur d' affectation (comme, par exemple, dans 1' instruc- 
tion :« poly. GetPoint (i) = Point{2,2); »). Certes, ce type d'ecriture est pratique, 
mais 1' ideal est tout de meme de renvoyer une valeur constante ou encore mieux, une 
reference constante, comme nous allons le voir plus loin, notamment au moment de 
l'etude de la fonction operator+ ( ) . 

Recommandation 

Les fonctions retournant un objet par valeur doivent en general renvoyer une valeur 
constante (sauf s'il s'agit d'un type predefini, comme int ou long). 



int GetNumPoints ( ) { return points_. size ( ) ; ) 

5. Meme commentaire qu'au point (3) : cette fonction devrait etre declaree const car 
elle ne modifie pas l'etat de l'objet. 

double GetAreaO 

{ 

if ( area_ < 0 ) 
{ 

CalcArea ( ) ; 

} 

return area_; 

} 



1. II n'y a aucun interet a renvoyer une valeur constante pour un type predefini, au 
contraire. Le fait q'une fonction renvoit un « const int » plutot qu'un « int » est non 
seulement inutile (un type de retour de type predefini ne peut de toute facon pas etre 
place a gauche d'une affectation), mais en plus dangereux (cela peut gener l'instancia- 
tion des modeles de classe ou de fonction). A ce sujet, voir aussi Lakos 96 (p. 618), 
auteur a propos duquel il faut d'ailleurs signaler qu'il n'est pas, contrairement a moi, 
favorable a l'emploi de valeur de retour const meme pour les types objets. 



// Si l'aire n'a pas ete calculee... 
// ...on la calcule 
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6. Cette fonction devrait, elle-aussi, etre declaree const. Ce n'est pas si evident car 
elle modifie effectivement l'etat de l'objet, settlement, il s'agit de l'etat interne de 
l'objet (mise a jour de la variable membre area_, utilisee ici pour mettre une valeur en 
cache, a des fins d'optimisation). D'un point de vue externe, l'appel de cette fonction 
laisse l'objet inchange. Autrement dit, la fonction GetAreaO modifie l'objet d'un 
point de vue physique mais laisse l'objet inchange d'un point de vue logique. 

La meilleure chose a faire ici est done de declarer const la fonction GetArea ( ) et 
d'appliquer l'attribut mutable a la variable area_, la rendant ainsi modifiable depuis 
une fonction membre constante. Voir a ce sujet le paragraphe « const et mutable : des 
amis qui vous veulent du bien ». 

Si votre compilateur n'implemente pas encore mutable, contournez le probleme 
en utilisant l'operateur const_cast sur la variable area_ (et inserez un commentaire 
dans votre code en prevision du jour ou mutable sera disponible) 

private : 

void InvalidateArea ( ) { area_ = -1; } 

7. Cette fonction devrait egalement etre declaree constante, par coherence avec le 
point precedent, car elle ne modifie pas l'etat externe de l'objet. En effet, a partir du 
moment ou il est decide que le mecanisme de mise en cache de l'aire dans la variable 
area_ est un detail d' implementation interne, il ne doit se manifester dans aucune des 
fonctions de 1' interface de la classe, fut-elle privee. 

void CalcArea ( ) 
{ 

area_ = 0; 

vector<Point> :: iterator i; 

f or ( i = point s_. begin () ; i != point s_ . end () ; ++i ) 
area__ += /* calcul de l'aire (non detaille ici) */; 

} 

8. La encore, cette fonction devrait etre declaree constante car elle ne modifie pas 
l'etat interne de l'objet. De plus, cette fonction doit pouvoir etre appelee depuis la 
fonction GetArea ( ) ,constante elle-aussi. 

9. L'iterateur utilise pour parcourir la liste ne doit pas modifier l'etat des objets 
points_. II devrait etre par consequent etre remplace par un const_iterator. 

vector<Point> points_; 
double area_; 

}; 

Polygon operatort ( Polygons lhs, Polygons rhs ) 

10. Les parametres ins et rhs devraient etre des references constantes, car les objets 
correspondants ne sont pas modifies par la fonction operator+ ( ) . 

11. Le type de retour de la fonction devrait etre const Polygon ou const Polygons 
(voir le point n° 4) 

Polygon ret = lhs; 

int last = rhs . GetNumPoints ( ) ; 



© copyright Editions Eyrolles 



Pb n° 43. Du bon usage de const 



187 



12. « int last » devrait etre remplace par « const int last », cette variable 
n'etant pas amenee a changer au cours de l'execution de la fonction. 

for ( int i = 0; i < last; ++i ) // concatenation des points 
{ 

ret . AddPoint ( rhs . GetPoint ( i ) ); 

} 

return ret; 

} 

On remarque qu'il n'est possible de rendre la fonction operator+ ( ) constante que 
si GetPoint ( ) renvoie une valeur (ou une reference) constante. 

void f ( const Polygons poly ) 
{ 

const_cast<Polygon&> (poly) .AddPoint ( Point (0,0) ); 

} 

Cette fonction declare un parametre de type reference constante, semblant ainsi 
indiquer a 1' appelant qu'elle ne modifiera pas l'objet reference. Or, dans son imple- 
mentation interne, elle supprime le caractere constant du parametre a l'aide d'un 
constjast afin d'appeler la fonction AddPoint o ! Soyez coherent : si un parametre 
n'est pas effectivement constant, ne le declarez pas const ! 

void g( Polygons const rPoly ) { rPoly . AddPoint ( Point (1,1) ); } 

13. Ce const est non seulement inutile (par definition, une reference pointe systema- 
tiquement toujours vers le meme objet), mais, qui plus est, il n'est pas conforme a la 
syntaxe C++. 

void h( Polygon* const pPoly ) { pPoly->AddPoint ( Point (2, 2) ); } 

14. Cette fois, la syntaxe est correcte, mais le const n'en est pas moins inutile, pour 
une raison legerement differente : a partir du moment ou le pointeur pPoly est passe 
par valeur, la fonction h o n'a aucune possibilite de faire pointer le pointeur original 
vers un objet different, puisqu'elle ne dispose que d'une copie de ce pointeur. 

int main ( ) 
{ 

Polygon poly; 

const Polygon cpoly; 

f (poly) ; 
Pas de probleme. 

f (cpoly) ; 

Le resultat de l'execution de cette ligne est indetermine, la fonction £() essay ant 
de forcer la modification d'un objet declare constant. Voir le point n° 12. 

g (poly) ; 

Pas de probleme. 
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h (spoly) ; 

} 

Pas de probleme. 

Pour finir, voici la version revisee de notre exemple (les divers points de style non 
relatifs au mot-cle const, notamment l'emploi abusif de fonctions en-ligne a des fins 
de concision, n'ont pas ete corriges). 

class Polygon 
{ 

public : 

Polygon () : area_(-l) {} 

void AddPoint ( Point pt ) { InvalidateArea ( ) ; 

points_.push_back (pt) ; ) 
const Point GetPoint ( int i ) const { return points_[i]; } 
int GetNumPoints ( ) const { return points_. size ( ) ; ) 

double GetAreaO const 
{ 

if ( area_ < 0 ) //Si l'aire n'a pas ete calculee... 

{ 

CalcAreaO; // ... on la calcule 

} 

return area_; 

} 

private : 

void InvalidateArea ( ) const { area_ = -1; } 

void CalcAreaO const 

{ 

area_ = 0; 

vector<Point> : : const_iterator i; 

for ( i = point s_. begin () ; i != point s_ . end () ; ++i ) 

{ 

area_ += /* calcul de l'aire (non detaille ici) */; 

} 

} 

vector<Point> points_; 
mutable double area_; 



const Polygon operatort ( const Polygons lhs, 

const Polygons rhs ) 

{ 

Polygon ret = lhs; 

const int last = rhs . GetNumPoints () ; 

f or ( int i = 0; i < last; ++i ) // concatenation des points 
{ 

ret .AddPoint ( rhs . GetPoint ( i ) ); 

} 

return ret; 

} 

void f ( Polygons poly ) 
{ 

poly .AddPoint ( Point (0,0) ); 

} 
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void g( Polygons rPoly ) { rPoly .AddPoint ( Point (1,1) ) ; ) 
void h( Polygon* pPoly ) { pPoly->AddPoint ( Point (2,2) ) ; ) 

int main ( ) 
{ 

Polygon poly; 
f (poly) ; 
g (poly) ; 
h (spoly ) ; 

} 



const et mutable : des amis qui vous veulent du bien 

II n'est pas rare de rencontrer des developpeurs reticents a l'idee d'utiliser const 
dans leurs programmes, sous pretexte qu'a partir du moment ou on commence a 
declarer const quelques arguments et quelques fonctions, il faut en general revoir, de 
proche en proche, l'integralite du programme. 

II est vrai que Futilisation de const represente un (petit) travail supplementaire au 
niveau du developpement - surtout lorsqu'il s'agit de reviser un programme existant 
n'utilisant que peu ou pas const. Neanmoins, les benefices que vous pourrez en retirer 
en terme de fiabilite, clarte et securite de votre code sont tels qu'il ne faut pas un ins- 
tant hesiter a faire cet investissement ! 

Une des grandes forces du langage C++ est la puissance d' analyse du compilateur, 
capable de reperer un tres grand nombre d' incoherences ou d'erreurs lors de la phase 
de developpement, reduisant d'autant le risque d'erreurs a 1' execution. Mais pour 
beneficier de cette puissance, encore faut-il utiliser les fonctionnalites correspondan- 
tes du langage : const est l'une d'entre elles. 

En resume, l'emploi de const permet d'accroitre significativement la qualite du 
code. Les developpeurs qui, par paresse, omettent de 1' utiliser ou - ce sont souvent les 
memes - negligent les avertissements (warnings) du compilateur s'exposent inutile - 
ment a des risques supplementaires. 

Sachez utiliser, lorsque c'est necessaire, le mot-cle mutable qui permet d'autoriser 
qu'une variable membre soit modifiee par une fonction membre constante. Ceci per- 
met, comme dans l'exemple vu plus haut, de declarer comme constante s des fonctions 
modifiant l'etat interne de l'objet sans en modifier l'etat externe. 

II est vrai que certaines bibliotheques du marche n'utilisent pas const comme elles 
le devraient. Si vous etes contraint d'utiliser une de ces bibliotheques, n'imitez surtout 
pas ses defauts ! Prenons l'exemple d'une fonction membre declaree non constante 
dans la bibliotheque alors qu'elle aurait du l'etre, vu son role. Cette erreur vous 
empeche d'invoquer la fonction en question sur un objet constant situe dans votre 
code. II y a alors deux solutions : la mauvaise consiste a supprimer les const de votre 
code (quelle erreur !), la bonne consiste a utiliser l'operateur const_cast sur votre 
objet, en attendant une meilleure version de la bibliotheque. 
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Finalement, l'une des meilleures justifications de l'importance de const est sans 
nul doute son introduction tres precoce au sein du langage C, des l'epoque des pre- 
miers comites de normalisation ANSI. Le const du C permet de qualifier des varia- 
bles; pour la petite histoire, voici comment est ne le const des fonctions membres : 
Lorsque au debut des annees 1980, un jeune chercheur nomme Stroustrup inventa le 
« C avec classes », il introduisit des le debut le mot-cle readonly permettant de quali- 
fier les membres d'une classe ne modifiant pas l'etat de l'objet. L'idee plut a Fequipe 
des Bell Laboratories, qui prefera neanmoins le mot-cle const. Vous connaissez la 
suite... (voir Stroustrup94, page 90) 

En resume, comme aime a le rappeler Scott Meyers (Meyers98, probleme n° 21) : 
« Utilisez const chaque fois que c'est possible ». Votre code ne sera que plus fiable, 
plus clair et plus sur. 



Pb n° 44. Operateurs de casting 



Difficulte : 6 



Ce probleme va vous permettre de tester votre connaissance des operateurs de casting C++. 
Employes a bon escient, ils peuvent etre d'une tres grande utilite. 



Les nouveaux operateurs de casting (transtypage) apportes par le C++ offrent plus 
de possibilites que l'ancienne technique utilisee en C (coercition de type en faisant 
preceder une variable par le type cible, entre parentheses). Les connaissez- vous bien ? 

Dans toute la suite de ce probleme, on se referera a 1' ensemble de classes et de 
variables globales suivant : 

class A { public: virtual ~A ( ) ; /*...*/ }; 
A::~A() { } 

class B : private virtual A { /*...*/ }; 
class C : public A { /*...*/ }; 

class D : public B, public C { /*...*/ }; 
A al; B bl; C cl; D dl; 
const A a2; 
const AS ral = al; 
const AS ra2 = a2; 
char c; 

Ce probleme comporte quatre questions. 

1. Parmi les nouveaux operateurs de casting C++, rappeles ci-dessous, lesquels n'ont 
pas d' equivalents dans l'ancienne technique de casting utilisee en C ? 

const_cast 
dynamic_cast 
reinterpret_cast 
static_cast 
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2. Reecrivez les instructions suivantes en utilisant les nouveaux operateurs de casting 
C++. Y a t'il, parmi elles, des instructions illegales sous leur forme originale ? 

void f() 
{ 

A* pa; B* pb; C* pc; 
pa = (A*) sral; 
pa = (A*) &a2; 
pb = (B*) &cl; 
pc = (C*) sdl; 

} 

3. Commentez toutes les instructions suivantes. Indiquez en particulier les instruc- 
tions non valides et celles dont le style est discutable. 

void g() 
{ 

unsigned char* puc = static_cast<unsigned char*> (Sc) ; 

signed char* psc = static_cast<signed char*>(&c); 

void* pv = static_cast<void*> ( Sbl ) ; 

B* pbl = static_cast<B*> (pv) ; 

B* pb2 = static_cast<B*> (&bl) ; 

A* pal = const_cast<A*> (Sral) ; 

A* pa2 = const_cast<A*> (Sra2) ; 

B* pb3 = dynamic_cast<B*> (&cl ) ; 

A* pa3 = dynamic_cast<A*> ( &bl ) ; 

B* pb4 = static_cast<B*> (Sdl) ; 

D* pd = static_cast<D*> (pb4 ) ; 

pal = dynamic_cast<A*> (pb2 ) ; 

pal = dynamic_cast<A*> (pb4 ) ; 

C* pel = dynamic_cast<C*> (pb4 ) ; 

C& rcl = dynamic_cast<C&> (*pb2) ; 

} 

4. Dans quels cas est-il utile d'utiliser const_cast pour convertir un objet non 
constant en objet constant ? Donnez un exemple precis. 



1. Parmi les nouveaux operateurs de casting C++, rappeles ci-dessous, lesquels 
n'ont pas d' equivalents dans Vancienne technique de casting utilisee en C ? 

Seul Foperateur dynamic_cast n'a pas d'equivalent. Tous les autres peuvent etre 
exprimes de maniere equivalente avec l'ancienne technique de casting utilisee en C. 



Recommandation 

Preferez les nouveaux operateurs disponibles en C++ a l'ancienne technique de casting 
utilisee en C. 
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2. Reecrivez les instructions suivantes en utilisant les nouveaux operateurs de cas- 
ting C++. Y a t'il, parmi elles, des instructions illegales sous leur forme originale ? 

void f() 
{ 

A* pa; B* pb; C* pc; 

pa = (A*) sral; 

Pour cette instruction, on utilisera l'operateur const_cast : 

pa = const_cast<A*> (&ral ) ; 

La deuxieme instruction pose probleme : 

pa = (A*)&a2; 

Cette instruction ne peut pas etre exprimee a l'aide d'un operateur de casting C++. 
Le candidat le mieux place aurait ete const_cast, mais il aurait risque de produire un 
resultat indetermine a 1' execution, a2 etant un objet constant. 

pb = (B*)Scl; 

Pour cette troisieme instruction, on utilisera reinterpret_cast : 

pb = reinterpret_cast<B*> ( &cl ) ; 
Et pour finir : 

pc = (C*)&dl; 

Cette derniere instruction est illegal e en C. En revanche, elle peut etre ecrite direc- 
tement en C++, sans recourir a aucun operateur de casting : 

pc = sdl; 

3. Commentez toutes les instructions suivantes. Indiquez en particulier les instruc- 
tions non valides et celles dont le style est discutable. 

Avant de rentrer dans le detail, une petite remarque d'ordre general : tous les 
appels a dynamic_cast dans l'exemple suivant seraient invalides si les classes mises 
en jeu ne comportaient pas de fonction virtuelle. Par chance, A en comporte une. 

void g() 
{ 

unsigned char* puc = static_cast<unsigned char*>(&c); 
signed char* psc = static_cast<signed char*>(&c); 

Erreur ! II faut utiliser reinterpret_cast pour ces deux lignes. En effet, char, 
signed et unsigned char sont consideres en C++ comme trois types bien distincts 
(bien qu'il existe des conversions implicites entre eux). 

void* pv = static_cast<void*> (&bl) ; 
B* pbl = static_cast<B*> (pv) ; 

Ces deux lignes sont correctes, mais dans la premiere, l'operateur static_cast est 
superflu, car pour tout pointeur, il existe deja une conversion implicite vers void*. 
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B* pb2 = static_cast<B*> (sbl) ; 
L'emploi de static_cast est ici correct, mais sans interet, &bi etant deja de type 

B*. 

A* pal = const_cast<A*> (Sral) ; 

La syntaxe correcte n'occulte pas un mauvais style de programmation. Dans la 
grande majorite des cas, il est recommande de ne pas alterer le caractere constant d'un 
objet. Si c'est pour appeler une fonction membre non constante, alors il est preferable 
de rendre la fonction constante et d'employer le mot-cle mutable, comme nous 
l'avons vu dans le probleme n° 43. 



Recommandation 

N'utilisez pas const_cast pour supprimer le caractere constant d'une reference. Modifiez plutot I'objet 
reference en specifiant I'attribut mutable pour les variables membres qui le necessitent. 



A* pa2 = const_cast<A*> (&ra2) ; 

Erreur ! contrairement au cas precedent, c'est I'objet reference par ra2 qui est 
constant, et non plus la reference. Par consequent, l'utilisation du pointeur pa2 ainsi 
obtenu risque de provoquer une erreur a 1' execution (I'objet constant a 2 aura pu, par 
exemple, etre stocke par le compilateur dans une zone de memoire en lecture seule). 
D'une maniere generate, il est dangereux de rendre non constant un objet constant. 



Recommandation 

N'utilisez pas constjast pour rendre non constant un objet constant. 



B* pb3 = dynamic_cast<B*> (Scl) ; 

Erreur ! Cette instruction va affecter a pb3 la valeur null, pour la bonne raison que 
ci n'est pas un objet derive de b. II s'ensuivra une erreur a l'execution si on tente 
d'utiliser le pb3 dans la suite du code. Le seul autre operateur dont la syntaxe est cor- 
recte ici aurait ete reinterpret_cast, dont il n'est meme pas besoin de preciser les 
consequences desastreuses dans cette situation. 

A* pa3 = dynamic_cast<A*> (sbl) ; 

Erreur aussi ! C'est moins evident de prime abord, car b derive effectivement de a. 
Mais cette derivation etant privee, bi « N'EST- PAS -UN » a ; par consequent, le resul- 
tat de cette operation sera un pointeur nul, a moins que g ( ) soitune fonction amie de b. 

B* pb4 = static_cast<B*> (Sdl) ; 

Cette instruction est correcte, mais l'emploi de static_cast est superflu car on 
peut toujours convertir implicitement un pointeur vers un objet derive en un pointeur 
du type d'une des classes de base. 
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D* pd = static_cast<D*> (pb4) ; 

Cette instruction est correcte. L'emploi d'un dynamic_cast aurait certes ete plus 
judicieux, mais il est tout a fait autorise d'utiliser un static_cast pour transformer un 
pointeur vers n'importe quel autre pointeur accessible de la meme hierarchie de classe. 
II aurait neanmoins fallu preferer ici un dynamic_cast, du fait qu'il limite le risque 
d'erreurs. En effet, si le pointeur a convertir pointe vers un objet derive de la classe du 
pointeur cible (« casting descendant »), tout se passe bien. Mais si, en revanche, il pointe 
vers un objet de base, cela risque de provoquer des erreurs a 1' execution difficiles a repe- 
rer dans le cas d'un static_cast (pointeur « partiellement valable ») alors que dans le 
cas d'un dynamic_cast, toute conversion invalide resultera en un pointeur nul. 



Recommandation 

Utilisez dynamic_cast plutot que static_cast pour realiser des « casting descendants ». 



pal = dynamic_cast<A*> (pb2 ) ; 
pal = dynamic_cast<A*> (pb4 ) ; 

Ces deux lignes sont relativement similaires, dans la mesure ou elles tentent toutes 
les deux de convertir un b* en a*. Pourtant, le resultat de la premiere conversion sera 
un pointeur nul, tandis que la deuxieme se deroulera correctement. Nous avons deja 
vu la raison plus haut : B derive de A de maniere privee, et, par consequent, 1' objet bi, 
vers lequel pointe pb2, « N'EST-PAS-UN » a, ce qui rend l'operation de conversion 
impossible. 

Dans ces conditions, pourquoi la deuxieme ligne s'execute-t-elle correctement ? II 
se trouve que pb4 pointe vers 1' objet di etqueD derive publiquement de a via la hie- 
rarchie d, c, a. L'operateur dynamic_cast est capable de naviguer au sein de la hierar- 
chie de classe afin d'atteindre la classe cible : en 1' occurrence, il aura effectue les 
conversions suivantes :b* -> d* -> c* -> a*. 

C* pel = dynamic_cast<C*> (pb4 ) ; 

Instruction correcte, en vertu de ce que nous venons de voir : la capacite de 
dynamic_cast a naviguer au sein d'une hierarchie de classe. 

C& rcl = dynamic_cast<C&> (*pb2) ; 

} 

Pour finir, une instruction qui generera une exception a 1' execution. En effet, il est 
clair qu'il n'est pas possible de convertir (*pb2) en une reference vers c car (*pb2) 
« N'EST-PAS-UN » c. Ce qui change, en revanche, e'est qu'avec des references, 
l'operateur n'a pas de moyen simple d'indiquer qu'une erreur produite. Ne pouvant 
pas renvoyer une hypothetique « reference nulle », l'operation genere done une excep- 
tion bad_cast. 

4. Dans quels cas est-il utile d'utiliser const_cast pour convertir un objet non 
constant en objet constant ? Donnez un exemple precis. 
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Dans les trois questions precedentes, nous n'avons utilise constjast que pour 
convertir des objets constants en objets non-constants. 

II faut savoir qu'il est egalement possible d'utiliser cet operateur pour effectuer 
l'operation inverse, a savoir rendre constant des objets non-constants. C'est d'un 
emploi rare; cela peut neanmoins etre utile dans le cas de fonctions surchargees ne dif- 
ferent que par le caractere constant ou non des parametres : 

void f ( T& ) ; 

void f ( const T& ) ; 

template<class T> void g ( T& t ) 
{ 

f ( t ) ; // Appelle f (Ts) 

f( const_cast<const T&>(t) ) ; // Appelle f (const TS) 

} 

Dans cet exemple, l'emploi de constjast pour convertir la reference a t en une 
reference constante est le seul moyen d'appeler specifiquement la fonction f (const 

T&) . 

Remarquons au passage que si to avait ete un modele de fonction (tem- 
piate<ciass t> void f (T) ; ), il aurait ete maladroit de l'appeler en utilisant la syn- 
taxe f (const_cast<const t&> (t) ) .Une instanciation specifique de la bonne version 
du modele aurait ete plus j udicieuse (f<const t & > ( t ) ) . 



Pb n° 45. Le type bool 



Difficulte : 7 



L'introduction du type bool en C++ se justifie t'elle vraiment ? N'aurait-il pas ete possible de 
I'emuler en utilisant les autres fonctionnalites du langage ? 

Le C++ introduit deux nouveaux types predefinis par rapport au C : bool, utilise 
pour stacker les variables booleennes, et wchar_t (qui etait un typedef en C), utilise 
pour stacker les caracteres codes sur deux octets. 

Etait-il necessaire d'introduire ce type bool ? Indiquez les diverses solutions qui 
auraient permis d'emuler le type bool en utilisant les fonctionnalites existantes du 
langage, en precisant les limites de chacune. 



II n'est pas possible d'obtenir une implementation exactement equivalente au type 
bool en utilisant les autres fonctionnalites du langage. C'est d'ailleurs la raison fonda- 
mentale pour laquelle ce type, ainsi que les mots-cles true et false, ont ete ajoutes au 
C++. 
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II existe neanmoins des implementations approchantes, que nous allons presenter 
ici en indiquant, pour chacune, ses inconvenients. 

II y a quatre principales options : utilisation de typedef, utilisation de #define, 
utilisation d'enum ou creation d'une classe booi. 

Option 1 : typedef (note : 8.5/10) 

Cette option consiste a definir un nouveau nom de type, correspondant a un type 
entier existant, int par exemple : 

// Option 1: typedef 

// 

typedef int bool; 
const bool true = 1; 
const bool false = 0; 

Cette solution n'est pas mauvaise, mais elle presente quelques inconvenients : 

■ Le type bool n'est pas considere comme un type separe du point de vue de la sur- 
charge des fonctions : 

// Fichier f.h 
void f ( int ) ; // 

void f ( bool ) ; // Redeclare la meme fonction ! 
// Fichier f . cpp 

void f ( int ) {/*...*/} //OK 

void f( bool ) {/*...*/) // Erreur, redefinition de f ! 

■ Le champ des valeurs possibles pour une variable bool n'est pas restreint a true et 
false : 

void f ( bool b ) 
{ 

assert ( b != true && b != false ); 
// Cette assertion peut potentiellement echouer ! 

} 

Cette option est done valable, mais pas ideale. 



Option 2 : #def±ne (note : 0/10) 

Cette option consiste a definir utiliser l'instruction #def ine du preprocesseur : 

// Option 2: #define 
// 

#define bool int 
#define true 1 
#define false 0 

Cette solution est bien entendu catastrophique. Elle presente non seulement les 
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defauts de 1' option 1, mais egalement tous les problemes habituels lies a 1' utilisation 
de #def ine (effets de bords, ecrasements de noms,...). A eviter. 



Option 3 : enum (note : 9/10) 

Cette option consiste a definir utiliser un type enumere : 

// Option 3: enum 
// 

enum bool { false, true }; 

Cette solution est relativement bonne, dans la mesure ou elle pallie les defauts de 
l'option 1 relatifs a la surcharge de fonction et aux champs des valeurs possibles. 

Elle pose malheureusement probleme dans le cas particulier des expressions 
conditionnelles : 

bool b; 

b = ( i == j ) ; / / Erreur de compilation ! 

Cela ne fonctionne pas, car il n'est pas possible de convertir implicitement un int 

en Un enum. 

Option 4 : class (note : 9/10) 

Comme, apres tout, nous utilisons un langage oriente-objet, pourquoi ne pas creer 
une classe bool ? 

class bool 
{ 

public : 
bool () ; 

bool ( int ); // Pour les conversions implicites 

bools operator= ( int ); // depuis le type 'int' 
//operator int(); // A voir... 
//operator void*(); // A voir... 
private : 

unsigned char b_; 

}; 

const bool true ( 1 ) ; 
const bool false ( 0 ) ; 

Cette classe repond pratiquement a nos besoins. Elle pose neanmoins un petit pro- 
bleme au sujet des operateurs de conversion marques « a voir » : 

■ Si ces operateurs sont definis, il risque de survenir les ennuis classiques lies a l'uti- 
lisation d' operateurs de conversion et/ou de constructeurs de conversion non 
explicites, notamment lorsqu'il s'agit de conversions de et vers des types simples 
(interferences lors de la resolution des appels de fonctions surchargees, notam- 
ment). Voir les problemes n° 20 et n° 39 pour plus de details a ce sujet. 
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Si ces operateurs ne sont pas definis, notre type booi risque de ne pas se comporter 
naturellement dans certains situations pourtant classiques : 

bool b; 
/*...*/ 

if ( b ) // Erreur si b ne dispose pas d'une conversion 
{ // automatique vers int 

/*...*/ 



Nous nous trouvons done face un petit dilemme : soit nous implementons ces ope- 
rateurs, au risque de perturber la surcharge des fonctions, soit nous les omettons, nous 
exposant ainsi a d'autres types de problemes. Dans aucun des cas, nous n'obtenons 
une classe booi equivalente au type booi predefini du C++. 

Resumons la situation : 

■ L'utilisation d'un typedef presente quelques inconvenients au niveau de la sur- 
charge des fonctions. 

■ Un #def ine presente non seulement les inconvenients du typedef mais egalement 
tous les problemes usuels lies au preprocesseur. 

■ Un enum interdit la conversion implicite du resultat d'une expression 
conditionnelle vers un booi (comme « b= (i == j) ») 

■ Une classe booi interdit soit la surcharge des fonctions, soit l'emploi d'un booleen 
dans une instruction conditionnelle (du type « if (b) »), en fonction de l'imple- 
mentation ou non des operateurs de conversions vers int ou void*. 

II apparait done clairement que le langage C++ avait vraiment besoin d'un type 
booi predefini, lequel est, signalons-le au passage, egalement utilise comme type de 
retour des expressions conditionnelles (ce qui n'aurait pas ete possible de realiser avec 
nos implementations - a part, a la rigueur, avec la quatrieme). 



Pb n° 46. Transferts d'appel 



Difficulte : 3 



II n'est pas rare d'avoir besoin de « fonctions de transferts » dont I'unique role est de transferer 
I'appel a une autre fonction, a laquelle le travail est sous-traite. Les fonctions de ce type ne sont 
pas tres complexes a implementer ; ce probleme, qui leur est consacre, sera pourtant I'occasion 
d'aborder une petite subtilite des compilateurs a ce sujet. 



Les fonctions de transferts sont couramment utilisees pour sous-traiter une tache a 
une autre fonction ou a un objet. II est important que ces fonctions soit performantes, 
sous peine de penaliser inutilement la vitesse d'execution du programme. 
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Examinez la fonction de transfert suivante : 

// Fichier f . cpp 

// 

tinclude "f.h" 
/*...*/ 

bool f ( X x ) 
{ 

return g ( x ) ; 



Vous parait-elle correctement implementee ? Sinon, que changeriez-vous ? 




Solution 



La fonction f ( ) doit avant tout etre performante. A ce titre, elle n'est pas optimale 
sous la forme presentee ici et pourrait etre amelioree sur deux points : 

1. Passer le parametre sous la forme d'une reference constante, et non pas par 
valeur. 

La fonction f o fait une copie de l'objet x qui lui est passe en parametre, puis 
passe a son tour cette copie a la fonction g ( ) . Cette copie inutile de x penalise les per- 
formances, alors qu'elle pourrait facilement etre evitee par l'emploi d'une reference 
constante au lieu du passage de parametre par valeur. 

C'est l'occasion ici de faire une petite remarque d'ordre historique : jusqu'en 
1997, il n'etait pas obligatoire d'utiliser un passage de parametre par reference afin 
d'eviter cette copie inutile. En effet, la norme C++ specifiait alors qu'un compilateur 
etait autorise a eliminer les parametres d'une fonction dont l'unique utilisation etait 
d'etre transferes a une autre fonction : le compilateur pouvait, a la place, passer direc- 
tement les parametres en question a la fonction appelee. Prenons un exemple : 

X my_x ; 

f ( my_x ) ; 

Face a un code de ce type, les compilateurs etaient autorises a passer my_x directe- 
ment a g, au lieu de creer une variable, copie de my_x, au sein de la fonction f { ) puis 
de passer cette variable ago. 

Le probleme est que cette technique d' optimisation, autorisee mais pas imposee, 
n'etait pas systematiquement implementee par tous les compilateurs. C'est la raison 
pour laquelle elle a ete remise en question, puis interdite, lors d'une reunion du comite 
de normalisation C++ a Londres en 1997. Elle a en effet ete jugee dangereuse dans la 
mesure ou il peut arriver qu'un programme utilise, a des fins d' implementation 
interne, le nombre d'appels effectues a un constructeur de copie. Ce nombre pouvait 
varier d'un compilateur a un autre, en fonction de la presence ou non de 1' optimisation 
en question. 



© copyright Editions Eyrolles 



200 Complements divers 



A l'heure actuelle, les seules situations oil le compilateur est autorise, a des fins 
d' optimisation, a passer outre l'appel d'un constructeur de copie sont les parametres 
de retour de fonction et les objets temporaires. 

Dans le cas de notre fonction f ( ) , la seule solution pour eviter une copie inutile est 
done de passer en parametre une reference constante au lieu d'une valeur. 



Recommandation 

Plutot que de passer des parametres par valeur, utilisez, lorsque cela est possible, des refe- 
rences constantes. 



Merae si, avant 1997, le recours a une reference etait optionnel (etant donne 1' opti- 
misation realisee alors par la majorite des compilateurs), il etait tout de meme 
conseille, a des fins de portabilite. 



Recommandation 

Ne fondez pas le bon fonctionnement de votre programme sur des optimisations realisees 
par le compilateur. 



2. Implementer la fonction f ( ) en ligne 

Cette optimisation est plus discutable et peut dependre du contexte : le fait d'ecrire 
une fonction en ligne (inline) augmentant sa rapidite d' execution mais augmentant 
egalement la taille du programme. 

Dans le cas des fonctions de transfert, pour lesquels le code est minimal et la rapi- 
dite d'execution, en general, fondamentale, l'ecriture en ligne s'impose. 

Mais attention ! L'emploi des fonctions en ligne doit etre reserve a des cas particu- 
liers comme celui-ci. 



Recommandation 

N'utilisez les fonctions en ligne (inline) que dans les cas tres specifiques ou la recherche de 
la performance est une contrainte majeure. 



Au passage, il faut signaler que le fait de declarer f ( ) en ligne presente 
l'inconvenient supplemental de rendre le code client dependant de 1' implementation 
de f ( ) et, en particulier, du prototype de g ( ) , et done, par consequent, des eventuelles 
declarations de types des parametres de g ( ) . Ceci augmente les dependances au sein 
du code, ce qui est d'autant plus dommageable que le code client n'avait absolument 
pas besoin d'appeler, ni done de connaitre g ( ) . 

En conclusion, les fonctions en ligne ont leurs avantages et leurs inconvenients. 
Elles doivent etre utilisees avec parcimonie, lorsque le contexte 1' impose. 
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Pb n° 47. Controle du flot d'execution Difficulte : 6 



Une bonne connaissance de I'ordre dans lequel les instructions d'un programme seront execu- 
tes est primordiale pour eviter les erreurs d'execution. C'est le sujet de ce dernier probleme. 



Examinez le code suivant et relevez toutes les instructions risquant de provoquer 
des problemes dus a une mauvaise maitrise de leur ordre d'execution. 

tinclude <cassert> 

finclude <iostream> 

finclude <typeinfo> 

#include <string> 

using namespace std; 

// Les lignes suivantes proviennent d'autres fichiers en-tete 

// 

char* itoa ( int valeur, char* buffer, int base ) ; 
extern int CompteurDeFichier s ; 

// Fonctions et classes et macros utilitaires 

// pour verifier la taille du tableau 

// 

template<class T> 

inline void Verif ierTaille ( T& p ) 
{ 

static int NumeroDuFichier= ++CompteurDeFichier s ; 
if( Ip.VerifierTaille () ) 

{ 

cerr << "Echec de la verification de taille" 
<< "fichier : " << NumeroDuFichier 
<< ", " << typeid(p) . name ( ) 
<< " a 1 ' adresse " 

<< stat ic_cast <void*> ( &p) << endl; 
assert ( false ) ; 

} 

} 

template<clas s T> 
class Verificateur 
{ 

public : 

Verif icateur ( T& p ) 

-Verificateur ( ) 
private : 

TS p_; 

}; 

f define VERIFIER_TAILLE Verif icateur<TypeTableau> V( *this ) 



: p_(p) { Verif ierTaille ( p_ ) ; } 
{ Verif ierTaille ( p_ ) ; } 
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// 

// TableauBase et conteneur sont des classes de base 
// non detaillees ici 

template<class T> 

class Tableau : private TableauBase, public conteneur 
{ 

typedef Tableau TypeTableau; 
public : 

Tableau) size_t Taillelnitiale = 10 ) 
: conteneur ( Taillelnitiale ) , 

TableauBase ( conteneur :: GetType ( ) ), 

TailleUtilisee_(0) , 

TailleTotale_(TailleInitiale) , 

buffer_(new T [TailleTotale_] ) 

{ 

VERIFIER_TAILLE; 



void Redimensionner ( size_t NouvelleTaille ) 
{ 

VERIFIER_TAILLE; 

T* oldBuffer = buffer_; 

buffer_ = new T [NouvelleTaille] ; 

copy ( oldBuffer, oldBuffer+ 

min (TailleTotale_, NouvelleTaille) , buffer_ ); 
delete[] oldBuffer; 
TailleTotale_ = NouvelleTaille; 



string Af f icherTailles ( ) 
{ 

VERIFIER_TAILLE; 
char buf [30] ; 

return string ( "Taille totale = 
+ itoa (TailleTotale_,buf , 10) 
+ ", taille utilisee = " 
+ itoa (TailleUtilisee_,buf , 10) ; 



bool Verif ierTaille ( ) 
{ 

if ( TailleUtilisee_ > 0 . 9*TailleTotale_ ) 

Redimensionner ( 2*TailleUtilisee_ ); 
return TailleUtilisee_ <= TailleTotale_; 

} 

private : 

T* buffer_; 

size_t TailleUtilisee_, TailleTotale_; 



int f ( intS x, int y = x ) { return x += y; 
int g( intS x ) { return x /= 2; 



© copyright Editions Eyrolles 



Pb n° 47. Controle du flot d'execution 203 



void main ( int, char* [ ] ) 
{ 

int i = 42; 

cout « "f(" << i « ") = " << f(i) << ", " 
<< "g(" << i << ") = " << g(i) << endl; 
Tableau<char> a (20); 

cout << a . Af f icherTailles ( ) << endl; 



Cet exemple de code comporte un tres grand nombre de problemes potentiels. 
Examinons-le ligne par ligne : 

finclude <cassert> 

finclude <iostream> 

#include <typeinfo> 

finclude <string> 

using namespace std; 

// Les lignes suivantes proviennent d'autres fichiers en-tete 
// 

char* itoa ( int valeur, char* buffer, int base ) ; 
extern int CompteurDeFichiers ; 

Cette declaration fait reference a une variable globale declaree dans un autre 
module, visiblement utilisee pour gerer un compteur de fichiers. En C++, l'ordre dans 
lequel les variables globales (incluant les membres statiques de classe) sont initiali- 
sers est indetermine. II y a done un risque d'utiliser CompteurDeFichiers dans notre 
code avant que son initialisation, situee dans un autre module, n'ait eu lieu. 



Recommandation 

Evitez I'utilisation de variables globales ou de variables membres statiques. Si vous etes 
contraints d'en utiliser, soyez conscients des regies qui regissent leur initialisation. 



// Fonctions et classes et macros utilitaires 

// pour verifier la taille du tableau 

// 

template<class T> 

inline void Verif ierTaille ( T& p ) 
{ 

static int NumeroDuFichier= ++CompteurDeFichiers; 

Voici justement un cas pratique pouvant poser probleme. Rien n'indique que la 
variable globale CompteurDeFichiers sera initialisee avant la variable membre stati- 
que NumeroDuFichier. Si, par exemple, la variable globale est initialisee avec une 
valeur non nulle (int CompteurDeFichiers = ioo ;) mais que 1' initialisation de la 



© copyright Editions Eyrolles 



204 Complements divers 



variable membre statique a lieu avant celle de la variable globale, alors le compte des 
fichiers commencera a 0 (valeur d'initialisation par defaut pour les types predefinis) 
au lieu de 100. 

if( Ip.VerifierTaille () ) 
{ 

cerr << "Echec de la verification de taille" 
<< "fichier : " << NumeroDuFichier 
<< ", " << typeid(p) .named 
<< " a l'adresse " 

<< static_cast<void*> ( &p) << endl; 
assert ( false ) ; 

} 

} 

template<class T> 
class Verificateur 
{ 

public : 

Verificateur ( T& p ) 

-Verificateur () 
private : 

T& p_; 

>; 

#define VERIFIER_TAILLE Verif icateur <TypeTableau> V( *this ) 

L'idee consistant a employer une macro verifier_taille creant un objet local de 
type Verif icateur<TypeTableau>, OU TypeTableau est Un typedef COrrespondant au 
type de l'instance de modele de classe Tableau, lequel fait appel a la fonction veri- 
f ierTaiiie ( ) qui provoque un arret du programme en cas d'incoherence (taille utili- 
see du tableau superieure a la taille allouee) est foncierement bonne. 

Ce code presente neanmoins le defaut de ne s'executer correctement qu'en mode 
debug, vu qu'il repose sur l'emploi de la fonction assert o . L'emploi d'assert o 
peut certes constituer un aide supplementaire, mais il aurait fallu prevoir un systeme 
de remontee d'erreur s'executant aussi bien en mode debug qu'en mode non-debug. 

// TableauBase et conteneur sont des classes de base 
// non detaillees ici 

template<class T> 

class Tableau : private TableauBase, public conteneur 
{ 

typedef Tableau TypeTableau; 
public : 

Tableau) size_t Taillelnitiale = 10 ) 
: conteneur ( Taillelnitiale ) , 

TableauBase ( conteneur :: GetType ( ) ), 

Si conteneur: : GetType o est une fonction membre statique (n'ayant par defini- 
tion acces qu'a des variables statiques), cet appel fonctionnera correctement. S'il 
s'agit, en revanche, d'une fonction membre normale retournant la valeur d'une varia- 



: p_(p) { Verif ierTaiiie ( p_ ) ; } 
{ Verif ierTaiiie ( p_ ) ; } 



© copyright Editions Eyrolles 



Pb n° 47. Controle du flot d'execution 205 



ble membre normale, il se posera un probleme du fait que l'objet de base conteneur 
ne sera pas encore initialise au moment de l'appel du constructeur de TabieauBase : 
en effet, les classes de base non virtuelles sont initialisees dans l'ordre de leur declara- 
tion, de gauche a droite (et, dans notre cas, TabieauBase est declaree avant 

conteneur). 



Recommandation 

Dans la liste d'initialisation d'un constructeur, faites toujours appel aux construc-teurs des 
classes de base dans l'ordre de leur declaration. 



TailleUtilisee_(0) , 
TailleTotale_ (Taillelnitiale) , 
buffer_(new T [TailleTotale_] ) 

Cette fois, il s'agit d'une grave erreur ! L' allocation de buf fer_ ne se fera absolu- 
ment pas correctement, car 1' initialisation des variables s'effectue dans l'ordre ou 
elles sont declarees dans la classe, en l'occurrence: 

buffer_(new T [TailleTotale_] ) , 

TailleUtilisee_(0) , 
TailleTotale_ (Taillelnitiale) 

Sous cette forme, qui correspond effectivement a l'ordre d'appel, il apparait claire- 
ment que la variable TaiiieTotaie_ n'est pas initialisee au moment de l'allocation de 
but f er_, ce qui conduit a un tableau d'une taille completement aleatoire ! 



Recommandation 

Dans la liste d'initialisation d'un constructeur, initialisez toujours les variables membres 
dans l'ordre de leur declaration dans la classe. 



{ 

VERIFIER_TAILLE; 

} 

La fonction verifierTaiiie o est appelee deux fois, depuis le constructeur et le 
destructeur de verif icateur : c'est une fois de trop. Neanmoins, en comparaison des 
autres problemes vus jusqu'ici, il s'agit la plus d'un detail d' optimisation que d'une 
veritable erreur. 

void Redimensionner ( size_t NouvelleTaille ) 
{ 

VERIF IER_TAILLE; 
T* oldBuffer = buffer_; 
buffer_ = new T [NouvelleTaille] ; 
copy ( oldBuffer, oldBuffert 

min (TailleTotale_, NouvelleTaille) , buffer_ ); 
delete[] oldBuffer; 
TailleTotale_ = NouvelleTaille; 
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} 

Cette fonction est mal implementee car elle ne se comportera pas correctement en 
presence d'exceptions. Ce n'est pas l'instruction « new t » qui est en cause (si celle-ci 
lance une exception bad_aiioc, les variables du programme resteront dans un etat 
coherent) mais l'operateur d'affectation de t invoque... par la fonction copy o, bien 
stir. Si une exception est generee au cours de cette operation de copie, la fonction 
Redimensionner o se terminera en laissant l'objet dans un etat incoherent (deux 
tableaux alloues, l'ancien et le nouveau ; plus de pointeur vers l'ancien tableau, done 
plus de moyen de le desallouer). 



Recommandation 

Assurez-vous que votre code se comporte correctement en presence d'exceptions. En par- 
ticulier, organisez votre code de maniere a desallouer correctement les objets et a laisser les don- 
nees dans un etat coherent, meme en presence d'exceptions. 



string Af f icherTailles ( ) 
{ 

VERIFIER_TAILLE; 
char buf [30] ; 
return string ( "Taille totale = ") 
+ itoa(TailleTotale_,buf , 10) 
+ ", taille utilisee = " 
+ itoa(TailleUtilisee_,buf , 10) ; 

} 

La fonction itoa ( ) qui realise la conversion d'un entier vers une chaine de carac- 
tere utilise le tableau de caracteres buf passe en parametres pour placer la chaine 
resultat. 

char* itoa ( int valeur, char* buffer, int base ) ; 

La fonction Aff icherTailles o risque de poser probleme du fait que les divers 
operandes des operateurs + ne seront pas toujours evalues dans le meme ordre - en 
fonction du compilateur utilise. Les appels successifs a itoa vont ainsi ecraser a cha- 
que fois la variable buf provoquant, dans certains cas, des resultats incoherents. Tout 
dependra de l'ordre dans lequel seront evalues les parametres de la fonction opera- 
tort () . 

Pour le voir plus clairement, reecrivons l'instruction return en utilisant la syntaxe 
complete de la fonction operatort (les appels sont toujours evalues de gauche a 
droite) : 

return 

operatort ( 
operatort ( 

operatorf ( string ( "Taille totale = "), 

itoa (TailleTotale_,buf , 10) ) , 
", taille utilisee = " ) , 
itoa (TailleUtilisee_,buf , 10) ) ; 
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Considerons, par exemple, que la taille totale vaut 10, la taille utilisee vaut 5 et 
interessons-nous a l'ordre d'evaluation des parametres de la fonction operator+ ( ) la 
plus exterieure. Si c'est le premier parametre qui est evalue d'abord, alors l'affichage 
sera correct (« Taille totale = 10, taille utiiisee= 5 ») car le resultat du pre- 
mier appel itoa o sera stocke dans un tableau temporaire, du fait de la composition 
de plusieurs operateurs + dans l'operande de gauche; ainsi, le fait que le second appel 
itoa ( ) ecrase la valeur de but sera sans consequence. Si, en revanche, c'est le second 
parametre qui est evalue en premier, alors l'affichage produit sera incorrect (« Taille 
totale = 10, taille utiiisee= 10 »), car le second appel a itoa ( ) ecrasera la 
valeur de but recuperee a Tissue du premier appel, laquelle n'aura pas, cette fois, ete 
stockee dans un tableau temporaire. 



Erreur a eviter 

N'ecrivez jamais du code dont I'execution depend de l'ordre d'evaluation des parametres 
d'une fonction. 



bool Verif ierTaille ( ) 

{ 

if ( TailleUtilisee_ > 0 . 9*TailleTotale_ ) 
Redimensionner ( 2*TailleUtilisee_ ) ; 

return TailleUtilisee_ <= TailleTotale_; 

} 

Cet appel a la fonction Redimensionner ( ) presente deux problemes : 

■ II y a, d'une part, un risque d' appel recursif a l'infini lorsque la condition 

( Taiiieutiiisee_ > o . 9*TaiiieTotaie_ ) est verifiee : en effet, la premiere 

chose que fait la fonction Redimensionner () est d'appeler la fonction Verif ier- 
Taille () , pour laquelle la condition en question sera toujours verifiee, ce qui va 

appeler a nouveau Redimensionner ( ) , etc. 

■ II y a, d' autre part, une difference de comportement genante entre le mode debug 
et les autres modes, du fait de l'utilisation de assert ( ) dans le modele de fonction 
globale verif ierTaille o comme unique moyen de remontee d'erreurs. Comme 
nous l'avons deja mentionne plus haut, il aurait fallu prevoir un systeme de remon- 
tee d'erreurs fonctionnant quel que soit le mode de compilation, debug ou non. 
C'est particulierement important dans le cas d'une fonction comme Redimension- 
ner ( ) qui risque fortement de ne pas etre appelee aux memes moments d'une exe- 
cution a l'autre, etant donne qu'elle depend de l'utilisation qui est faite de Tableau 
par le code client. 

private : 

T* buffer_; 

size_t TailleUtilisee_, TailleTotale_; 

}; 

int f ( int& x, int y = x ) { return x += y; } 
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Cette declaration de fonction est illegale et un compilateur conforme a la norme 
C++ devrait normalement la rejeter. Nous considererons, dans la suite, que la valeur 
par defaut de y est 1. 

int g( intS x ) { return x /= 2; } 

void main ( int, char*[] ) 
{ 

int i = 42; 

cout << "f(" << i << ") = " << f(i) << ", " 
<< "g(" << i << ") = " << g(i) << endl; 

La encore, voici un exemple de code dont l'execution depend de l'ordre d'evaluation des 
parametres : il n'est pas possible de prevoir l'ordre dans lequel seront appelees les fonctions f ( ) 
et g o , ni la valeur de i aux moments ou on tentera de l'afficher. Un compilateur bien connu, 
produit, par exemple, le resultat suivant : « f ( 22 ) =2 2 , g ( 2 1 ) =2 1 »). 

Ce n'est pas le compilateur qui est en tort, mais bien l'auteur de ces lignes. 



Erreur a eviter 

N'ecrivez jamais du code dont l'execution depend de l'ordre d'evaluation des parametres 
d'une fonction. 



Tableau<char> a (20); 

cout << a .Af ficherTailles () << endl; 

} 

Ceci devrait normalement afficher « Taiiie totaie = 20, taiiie utiiisee = 
0 ». Malheureusement, il se peut que le resultat soit different, du fait des problemes de 
la fonction At f icherTaiiies o , detailles plus haut. 

En conclusion, une bonne connaissance des mecanismes de flot d' execution 
(notamment, de ce qui est indetermine) est une condition necessaire pour l'ecriture de 
bons programmes C++. 
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Post-scriptum 



Si les problemes presentes dans cet ouvrage vous ont plu, sachez que vous pourrez 
regulierement retrouver des articles similaires sur le groupe de discussion Internet 
comp. lang. c++ .moderated et consulter les numeros passes de Guru Of The Week sur 
http://www.peerdirect.com/resources (ce livre est inspire des problemes n° 1 a 30 ; a 
la date de septembre 2000, nous en sommes au probleme n° 73). 

Voici un petit apercu des sujets traites dernierement : 

■ Une etude approfondie de l'utilisation d'auto_ptr, des espaces de nommage et de 
la gestion des exceptions, dans la lignee des elements deja etudies dans les proble- 
mes n° 8 a 17, 31 a 34 et 37 de ce livre) 

■ Une serie de trois problemes relatifs au comptage de reference, notamment dans le 
contexte d' applications multi-thread, abordant des sujets rarement discutes auparavant. 

■ De nombreux problemes relatifs a la bibliotheque standard, notamment a l'utilisa- 
tion et l'extensibilite des conteneurs (vector, map) et des flux d'entree-sorties, 
dans la lignee du probleme n° 3 de ce livre. 

■ Un jeu de Master-Mind ecrit avec le minimum d' instructions possible. 
Et ce ne sont la que quelques exemples parmi d'autres. 

Par ailleurs, sachez qu'il est dans mes projets d'en preparer une suite, inspiree des 
nouveaux problemes parus sur Guru Of The Week et des divers articles et editoriaux 
que j'ecris pour C/C++ Users Journal et d'autres magazines. 

J'espere que ce livre vous a plu et que vous continuerez a me faire part de vos desi- 
derata en matiere de sujets traites. Sachez au passage que plusieurs des sujets abordes 
dans ce livre l'ont ete suite a des demandes de lecteurs parvenues par le biais du site 
Internet cite plus haut. 

Merci a tous ceux qui m'ont exprime leur interet et leur soutien au sujet de Guru 
Of The Week et de ce livre. Puisse-t-il etre votre compagnon au quotidien dans la reali- 
sation de programmes plus fiables, plus robustes et plus performants. 
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